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

Alexey Samsonov vonosmas at gmail.com
Fri May 30 15:12:03 PDT 2014


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 think so. Will update the patch.


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

We likely need both for this case - e.g. local vars in ASan are usually
described
by stack pointer, while function arguments (as the one in PR19307) may be
described
via frame pointer.


>
> >
> >>
> >> >
> >>
> >> :)
> >>
> >> >> 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/3d57de21/attachment.html>


More information about the llvm-commits mailing list