[llvm-dev] RFC: Setting MachineInstr flags through storeRegToStackSlot

[Alex Bradbury via llvm-dev]

On 2 March 2017 at 14:22, Alex Bradbury <asb at asbradbury.org> wrote:
> On 21 February 2017 at 18:23, Robinson, Paul <paul.robinson at sony.com> wrote:
>
>> In DWARF, the idea is that if the debugger is doing a "step in" operation
>> for a call to the function, where is the most reasonable place to stop
>> execution, that is still "before" the first statement?  Debug info for
>> parameters and local variables commonly points to stack frame slots, so
>> generally it's not helpful (for the user) to stop before the stack/frame
>> pointer is set up the way the debug info expects.
>>
>> Stashing callee-saved registers is not necessarily part of this, although
>> if you're using the stack pointer as a frame pointer and doing pushes to
>> save registers, you need to be done fiddling with SP before you can say
>> the prologue is ended.
>> --paulr
>
> Thanks. I'm starting to think the better fix might be to add an
> iterator argument to emitPrologue and emitEpilogue to indicate
> after/before the callee-saves. Does anyone have particular views on
> this one way or another?

I'd like to return to this, as I really want to be able to reuse the
standard logic in PrologEpilogInserter without having to make
assumptions that may break in the future (e.g. that every callee-saved
register spill takes a single instruction).

>From the discussion in this thread and the strawman patch
(https://reviews.llvm.org/D30115), I think that adding FrameSetup or
FrameDestroy flags to all CSR spills/restores is probably not the
right way to go (although some backends do choose to do this).

I propose:
* Modifying TargetFrameLowering::emitPrologue to take a
MachineBasicBlock::iterator 'AfterCSRSaves', pointing to the
instruction after any inserted callee-save register spills. The
insertCSRSaves helper can easily be modified to return this iterator
* Modifying TargetFrameLowering::emitEpilogue to take a
MachineBasicBlock::iterator 'FirstCSRRestoreOrTerminator'.
insertCSRRestores can be modified to return this iterator, though a
little care needs to be taken for the case where a BB only has a
single instruction.

In both cases, these iterator arguments are intended to be exactly
what you need in emitPrologue/emitEpilogue when determining where to
insert the frame setup / destruction code. I'm bringing it to the
mailing list again as the above solution still feels inelegant somehow
- though does seem an improvement over the status quo.

Does anybody have any thoughts on this, or alternative approaches they
would like to propose?

Thanks,

Alex