[PATCH] Generate better location ranges for some register-described variables.

[Eric Christopher]

On Fri, May 30, 2014 at 3:03 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Fri, May 30, 2014 at 3:00 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:
>>
>> On Fri, May 30, 2014 at 12:45 PM, Eric Christopher <echristo at gmail.com>
>> wrote:
>>>
>>> On Fri, May 30, 2014 at 10:26 AM, Adrian Prantl <aprantl at apple.com> wrote:
>>> >
>>> >> On May 29, 2014, at 10:03 PM, Alexey Samsonov <vonosmas at gmail.com>
>>> >> wrote:
>>> >>
>>> >> Yeah, well, we can add "FrameTeardown" machine instruction flag in
>>> >> addition to "FrameSetup", and annotate machine instructions added in frame
>>> >> lowering code. But do we expect many users of this flag (assuming that this
>>> >> usage is also somewhat questionable)?
>>> >
>>> > The FrameSetup flag is also only used by the debug info, so at least it
>>> > wouldn’t be any more questionable than that :-)
>>
>>
>> OK. Why don't we land the patch as-is now (don't terminate the register at
>> the end of MBB if this register is only modified in frame setup and the last
>> MBB - it should be safe), and then replace "the last MBB" condition with
>> checking a "FrameTeardown" flag, attached to certain machine instructions?
>> In this way we won't have to special-case certain registers and make
>> assumptions about their constant-ness.
>
> Given the limited nature of this fix (both in the fix's possible scope
> and intent/purpose) I'm personally sort of inclined to do this by
> whitelisting certain registers instead, if that were/is possible...
> seems simpler and still sufficient for the required purpose here.
>
> Can we easily just test whether a register is the stack/frame pointer?
> (I actually know so little about this that the difference between
> those two things isn't straight in my head and I'm not sure which, or
> both, we need for the common/intended case here)
>

If we need to stack realign we might not be able to do this as easily.
I'm not a huge fan of either method, but I think that the assumption
that Alexey has might make more sense than whitelisting. My logic:
Whitelisting involves assuming that various registers won't be used in
ways that surprise us and I can think of a few ways where it could
happen: stack realignment, inline asm, a smarter stack coloring
algorithm.

-eric

>>
>>>
>>> >
>>>
>>> :)
>>>
>>> >> I can also make this patch even less general and just special-case the
>>> >> frame pointer and the stack pointer registers, so that the code wouldn't
>>> >> pretend to solve a general problem we're facing.
>>> >
>>> > The frame pointer should be stable over the entire function, special
>>> > casing it seems to be appropriate. I don’t know whether, e.g, stack coloring
>>> > would cause the stack pointer to be modified in the middle of a function.
>>> >
>>>
>>> FWIW it may not _now_ but there's nothing from stopping it either. :\
>>>
>>> -eric
>>
>>
>> --
>> Alexey Samsonov
>> vonosmas at gmail.com