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

Alexey Samsonov vonosmas at gmail.com
Fri May 30 15:20:23 PDT 2014


On Fri, May 30, 2014 at 3:12 PM, Eric Christopher <echristo at gmail.com>
wrote:

> 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.
>

Stack realignment usually happens in function prologue / frame setup, so I
don't
immediately see the way it would hurt us. But the inline asm case is indeed
interesting.
I know too little of stack coloring to make a judgement. I though it just
minimizes
the number of stack slots so that we can re-use the same stack slot for
different
independent variables, but the actual stack pointer modifications are not
performed
in the middle of the function, but probably this could change over time:

void foo() {
  {
    int a[100];
  }
  {
    int b;
    // "a" is inaccessible, why not save the stack space used to store "a"
    // before we call "bar" ?
    bar();
  }
}


>
> -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
>



-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140530/f2eeefb2/attachment.html>


More information about the llvm-commits mailing list