[DebugInfo@O2] CodeGenPrepare drops reference to local in dbg.value intrinsic

[wolfy1961]

Bugzilla Link	39845
Resolution	FIXED
Resolved on	Dec 14, 2018 09:23
Version	trunk
OS	All
Blocks	#38116
CC	@jmorse,@pogo59,@wjristow
Fixed by commit(s)	r348896

Extended Description

extern void use(int);
extern int foo(long long);

void test(int p)
{
int i = p + 4;
(void)foo(i); // sign extension of i
if (p)
return;
use(i); // use of original i
}
// =====================================

Compile with -g -O2.

CodeGenPrepare seems to drop a reference to a local from a dbg.value
intrinsic:

*** IR Dump Before CodeGen Prepare ***
...
entry:
call void @​llvm.dbg.value(metadata i32 %p, metadata !​12, ...
%add = add nsw i32 %p, 4, !dbg !​15
call void @​llvm.dbg.value(metadata i32 %add, metadata !​13, ...

*** IR Dump After CodeGen Prepare ***
entry:
call void @​llvm.dbg.value(metadata i32 %p, metadata !​12, ...
%add = add nsw i32 %p, 4, !dbg !​15
call void @​llvm.dbg.value(metadata !​2, metadata !​13, ...

with:
!​2 = !{}
!​13 = !DILocalVariable(name: "i", scope: !​7, ...

So "i" does not get any location information in the .o.
If we change "foo" to take an int instead of a long long, the reference
is not dropped, and i has good location info.

On initial investigation it seems that CodeGenPrepare tries to
optimize sign/zero extensions and in the process replaces all uses of operands that it found worthy of extension with the extended versions.
When it finds that the optimization is not worth it (after it has already
performed it), it attempts to undo the replacement, but fails to restore
the Metadata uses.

It might be worth assessing whether this optimization is really all that useful, or find a way to restore the Metadata uses correctly.

[pogo59]

Might want to collect some stats on how often CGP decides to back it out;
also might try speculatively nuking the optimization and see if there's
any effect on final emitted code.

[wolfy1961]

Might want to collect some stats on how often CGP decides to back it out;
also might try speculatively nuking the optimization and see if there's
any effect on final emitted code.

CGP uses the rollback technique on a variety of optimizations it attempts. In the example I'm using the statistics indicate that the number of rollbacks is quite large (in one case, in a 900 line file it's rolling something back over 4000 times). Now, these are total rollbacks, not just sign/zero extends, so I'm afraid nuking this one optimization would still leave the problem in place for all the others.

It feels like it would be best to teach it to properly roll back Metadata in debug instructions. That way we would eliminate this category of problems wholesale.

[wolfy1961]

Fixed with r348896.