[llvm-branch-commits] [llvm] [LivePhysRegs] Add callee-saved regs from MFI in addLiveOutsNoPristines. (PR #73553)

Eli Friedman via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Tue Dec 12 14:09:53 PST 2023


efriedma-quic wrote:

> After PEI the liveness of LR needs to be accurately reflected and tail calls could (should?) always "use" LR. That would either prevent outlining or cause the outliner to preserve LR across introduced calls.

I'll elaborate on this a bit.  I think long-term, the way we want to model this is that pre-PEI, LR is treated as if it were a callee-save register.  (Nothing outside the prologue/epilogue should interact with the return address directly except for a few special cases like __builtin_return_address.)  Then PEI marks the LR use on the relevant "return" instructions, and post-PEI it's not callee-save anymore.  I think that correctly models the underlying weirdness: at a machine level, the return address is basically just an argument to the function, but it's special to PEI because of the interaction with the frame layout/exception handling/pop instructions/etc.  Stuff before PEI doesn't need to be aware it's an argument, and stuff after PEI can just treat it as a normal register.

> On the caller side, the call instruction clobbers LR, so it can't really be considered live-out

Correct, it's not really live-out.

-------

Short-term, can we make this fix a bit more targeted?  The point of the "isRestored" bit is that it's supposed to avoid marking liveness when the function ends in a "pop pc".  The relevant code is ARMFrameLowering::emitPopInst: it calls `Info.setRestored(false);` to do precisely this.  But it's triggering in a case where it shouldn't.  I think the problem is that the code isn't accounting for the possibility that there are other paths that return from the function.

https://github.com/llvm/llvm-project/pull/73553


More information about the llvm-branch-commits mailing list