As discussed in https://reviews.llvm.org/D46525, here is my attempt to remove debug intrinsics in StripDebugInfo.
tyb0807 on May 13 2018, 3:59 PM.Authored by
UPD: There are 3 regression tests that declare functions starting with llvm.dbg. (e.g. declare void @llvm.dbg.func.start(metadata) nounwind readnone) and are failing:
Should I change those functions' name so that the new code might work? Or should I change the if statement to if (F.getName() == "llvm.dbg.declare" || F.getName() == "llvm.dbg.value" || F.getName() == "llvm.dbg.addr") ?
Thanks for the patch.
Yes please commit this on my behalf.
Thanks a lot
Yes, you'll have to do opt -strip-debug -strip-dead-prototypes. What is done in strip-dead-prototypes is exactly what we do here though... I'm not sure what would cause the ThinLTO test fail...
Opt's -strip-dead-prototypes mode does exactly this.
echo "declare i32 @foo()" | ./bin/opt -strip-dead-prototypes -S -o - (empty)
I don't think it's necessary to teach StripDebugInfo() to do the same thing.
If you have spare cycles, could you try to take a look at debug value loss in instcombine? I started looking at this issue circa r323570 but got sidetracked with other work.
Anastasis has a great writeup on his blog about how to find bugs in this area. See: https://gramanas.github.io/posts/finding-debuginfo-loss/.
Here's one example you might look at:
$ ./bin/opt -enable-debugify -instcombine ../llvm/test/Transforms/InstCombine/zext.ll -S -o -
Each missing variable corresponds to some DILocalVariable which has no corresponding llvm.dbg.value instruction. Ideally we'd be able to emit a debug intrinsic for each variable using simple and non-intrusive methods. Keep in mind that this may not always be possible.