<p dir="ltr"><br>
On Jun 2, 2015 12:43 PM, "Sergey Dmitrouk" <<a href="mailto:sdmitrouk@accesssoftek.com">sdmitrouk@accesssoftek.com</a>> wrote:<br>
><br>
> > This still seems to have some oddities that are increasing the size of -gmlt<br>
> > in particular by creating discontiguous instruction ranges for inlined<br>
> > subroutines in ways that are possibly incorrect-ish.<br>
> ><br>
> > Take this example:<br>
> ><br>
> > volatile int x;<br>
> > int y;<br>
> > static __attribute__((always_inline)) int f1() {<br>
> >   if (x * 3 < 14) return 1;<br>
> >   return 2;<br>
> > }<br>
> > int main() {<br>
> >   x = f1();<br>
> >   x = x ? 1 : 2;<br>
> > }<br>
> ><br>
> > & the assembly difference: <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.diffchecker.com_p2ladh2w&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=AdejmYH0DNCs0JQ1TlRGdY4j3J6FmfbmziRT0tS7ci8&s=oDppY83lCSFgfm_PitPq84qOe2-WFFnmpqDMnGQ-YVY&e=">https://www.diffchecker.com/p2ladh2w</a><br>
> ><br>
> > What happens is that the 1 stored to x from the inlined f1() ends up being<br>
> > emitted indirectly (in this particular instance - setg/movzbl/incl so if the<br>
> > condition is false it's 1 + 1 and if it's true it's 0 + 1) so when the 1 is<br>
> > needed in main it's emitted directly there, but still attributed to the<br>
> > location inside f1.<br>
><br>
> Thanks for detailed explanation, David.</p>
<p dir="ltr">Sure thing, I'm glad it was helpful.</p>
<p dir="ltr">> > Does this still qualify as two uses of the constant '1' & should not get<br>
> > locations? Or does that first indirect emission not count as a use at this<br>
> > level - yet we somehow still use that use's location for the other use... ?<br>
><br>
> These are two uses, but this time constant node is queried in a<br>
> different way: in SelectionDAGBuilder::getNonRegisterValue() method via<br>
> value-to-sdnode map during matching phi-node values.  Later first use<br>
> disappears and we left with incorrect location.</p>
<p dir="ltr">I haven't quite wrapped my head around this - and won't until Thursday at least.</p>
<p dir="ltr">> Not sure how to handle this yet, a couple of obvious tries causes test<br>
> failures, will look for something better.</p>
<p dir="ltr">Given the debug info size/quality regression here - perhaps we could disable this again, temporarily, until we have an answer?</p>
<p dir="ltr">><br>
> --<br>
> Sergey<br>
</p>