[llvm] r288851 - [BDCE/DebugInfo] Preserve llvm.dbg.value's argument.

[Davide Italiano via llvm-commits]

On Wed, Dec 7, 2016 at 2:23 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> Hi David,
>

Hey Hal, thanks for the post-comment review.

> While this will certainly make the situation much better, it does not completely solve the problem. If you have an instruction that may have side effects, has a llvm.dbg.value, also has other uses, and BDCE can show that those other uses don't depend on the value (i.e. there are no demanded bits), then we'll still end up with the same problem. BDCE will end up breaking the value dependency edge between the instruction and the llvm.dbg intrinsic when it breaks the dependency edge with the other users.
>

Yes, it seems this can break pretty easily :(
Just adding a `xor %call %call` immediately after the dbg.value call
causes %call to have a non-dbg use which doesn't depend on the bits,
so call is trivialized and we lose the information anyway.

define void @f() !dbg !6 {
entry:
  tail call void (...) @h(), !dbg !9
  %call = tail call i32 (...) @g(), !dbg !10
  tail call void @llvm.dbg.value(metadata i32 %call, i64 0, metadata
!11, metadata !13), !dbg !14
  %x = xor i32 %call, %call
  tail call void (...) @h(), !dbg !15
  ret void, !dbg !16
}

> We had chatted on IRC about the possibility of creating some RAUWExceptDbg function. You said this got ugly, but maybe we should do something a bit simpler: make a RAUWExceptMetadata function. The implementation of RAUW looks like this:
>

This probably make sense. I'm not super happy about introducing
another API but it seems necessary in this case and removing the
metadata looks like a decent compromise.
I'll submit a review soon. Thanks!

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare