What's the "right" way to find out which machine register acts as the
stack pointer? I'm working on enhancing Fernando's register allocator
debugger and would like to add support for stack pointer semantics.
TargetRegisterInfo has a getFrameRegister method but that returns
(on x86) either ESP/RSP or EBP/RBP depending on whether frame
pointer elimination has been done.
Would it be ok to add a getStackPointerRegister method to TargetRegisterInfo?
-Dave
Why do you need to do this in a register allocator? Typically you want to refer to abstract frame indices. Wouldn't fernando's debugger use a similar representation?
-Chris
I don't need it in the allocator. I need it in Fernando's spiller that prints
the IR used by the debugger. The IR includes references to the stack
pointer. I need to add some sMira IR instructions at the top of the function
to define the stack pointer (and other things) so it isn't flagged as
undefined by the debugger.
I suppose we could change Fernando's IR so it works with abstract stack
indices but there are other times I've wanted to know the stack pointer as
well, especially when dumping debug info.
-Dave
similar representation?
I don't need it in the allocator. I need it in Fernando's spiller that prints
the IR used by the debugger. The IR includes references to the stack
pointer. I need to add some sMira IR instructions at the top of the function
to define the stack pointer (and other things) so it isn't flagged as
undefined by the debugger.
It sounds like the debugger is operating at the wrong abstraction level here. If it's just the RA debugger, using frame indices makes the most sense.
I suppose we could change Fernando's IR so it works with abstract stack
indices but there are other times I've wanted to know the stack pointer as
well, especially when dumping debug info.
I'm not sure what you mean here. If this is for debug dumps in the register allocator, dumping the stack pointer would be the *wrong* thing, because the frame indexes may end up being relative to the SP or the BP.
-Chris