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

[Hal Finkel via llvm-commits]

----- Original Message -----
> From: "Davide Italiano" <davide at freebsd.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Wednesday, December 7, 2016 1:48:45 PM
> Subject: Re: [llvm] r288851 - [BDCE/DebugInfo] Preserve llvm.dbg.value's argument.
> 
> 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!

Thanks!

 -Hal

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

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory