https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119174
--- Comment #13 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to Jeffrey A. Law from comment #11) > Andrew. You're missing the point. This scenario isn't the kind of thing > that reload and LRA are supposed to fix. They fix constraint problems. ie, > I got the wrong kind of register (wrong register file), or I can't really > handlea constant, so reload the value into a register, etc. > > We have a pseudo live across a call and IRA allocates that pseudo to a call > clobbered hard register. That's an IRA bug in my book. I think Andrew's comment 10 is right. Using call-clobbered registers for values that are live across a call is a deliberate choice, and like Andrew says is what -fcaller-saves is designed to do. All the recent patch did is tweak the costs around doing that. For LRA, the job of handling caller saves is integrated into LRA itself. For reload, it's instead handled by caller-save.cc. And I think that's the problem. All caller-save.cc knows how to do is to store a pseudo register before the call and restore the register before its next use (or at the end of the block, whichever is sooner). The increment emitted by reload will then be lost. So I suppose the tailored fix would be to avoid allocating a call-clobbered register to a pseudo P if reload is being used and if P is mentioned in a REG_INC note on a call. But it's probably easiest just to disable -fcaller-saves for reload targets instead.
