[llvm] r237237 - [DebugInfo] Debug locations for constant SD nodes

[David Blaikie]

On Jun 2, 2015 12:43 PM, "Sergey Dmitrouk" <sdmitrouk at accesssoftek.com>
wrote:
>
> > This still seems to have some oddities that are increasing the size of
-gmlt
> > in particular by creating discontiguous instruction ranges for inlined
> > subroutines in ways that are possibly incorrect-ish.
> >
> > Take this example:
> >
> > volatile int x;
> > int y;
> > static __attribute__((always_inline)) int f1() {
> >   if (x * 3 < 14) return 1;
> >   return 2;
> > }
> > int main() {
> >   x = f1();
> >   x = x ? 1 : 2;
> > }
> >
> > & the assembly difference: https://www.diffchecker.com/p2ladh2w
> >
> > What happens is that the 1 stored to x from the inlined f1() ends up
being
> > emitted indirectly (in this particular instance - setg/movzbl/incl so
if the
> > condition is false it's 1 + 1 and if it's true it's 0 + 1) so when the
1 is
> > needed in main it's emitted directly there, but still attributed to the
> > location inside f1.
>
> Thanks for detailed explanation, David.

Sure thing, I'm glad it was helpful.

> > Does this still qualify as two uses of the constant '1' & should not get
> > locations? Or does that first indirect emission not count as a use at
this
> > level - yet we somehow still use that use's location for the other
use... ?
>
> These are two uses, but this time constant node is queried in a
> different way: in SelectionDAGBuilder::getNonRegisterValue() method via
> value-to-sdnode map during matching phi-node values.  Later first use
> disappears and we left with incorrect location.

I haven't quite wrapped my head around this - and won't until Thursday at
least.

> Not sure how to handle this yet, a couple of obvious tries causes test
> failures, will look for something better.

Given the debug info size/quality regression here - perhaps we could
disable this again, temporarily, until we have an answer?

>
> --
> Sergey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150602/ffb8f55f/attachment.html>