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

[Davide Italiano via llvm-commits]

On Wed, Dec 7, 2016 at 12:06 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- 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!
>

https://reviews.llvm.org/D27534

-- 
Davide

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