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

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 16 01:50:51 PDT 2017


On 16 March 2017 at 00:01, Eric Christopher <echristo at gmail.com> wrote:
>
>
> On Thu, Mar 2, 2017 at 6:22 AM 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?
>>
>
> Scheduling can interfere with this as you might schedule or move something
> before saves on occasion.

The process of inserting the callee-save spills and prolog+epilog is
all handled from PrologEpilogInserter (see PEI::runOnMachineFunction).
It seems to me the only chance for things to go wrong after
SpillCalleeSavedRegisters is that the target-specific
processFunctionBeforeFrameFinalized moves instructions around, thus
invalidating the positions of the callee saves/restores.

Best,

Alex


More information about the llvm-dev mailing list