thr3ads.net - llvm dev - [LLVMdev] Valid debug information being deleted by DAGCombiner [Apr 2011]

If this information is useful, please help other people find it:
Share via:

John Criswell

2011-Apr-15 02:07 UTC

[LLVMdev] Valid debug information being deleted by DAGCombiner

On 4/14/11 8:22 PM, Villmow, Micah wrote:>
> Found another bitcode file where a debug symbol is being dropped.
>
> In the attached bitcode file, the variable gid is not in the debug output.
>
Dumb question: Have you looked to see if mem2reg is destroying (or not 
maintaining) the debug information of interest (or put another way, was 
the variable gid promoted to an LLVM register and therefore had its 
debug information destroyed)?

I haven't used LLVM's new debug facilities, so my knowledge is out of 
date, but I think optimizations are still permitted to remove debug info.

-- John T.
> *From:*llvmdev-bounces at cs.uiuc.edu 
> [mailto:llvmdev-bounces at cs.uiuc.edu] *On Behalf Of *Villmow, Micah
> *Sent:* Thursday, April 14, 2011 5:31 PM
> *To:* llvmdev at cs.uiuc.edu
> *Subject:* [LLVMdev] Valid debug information being deleted by DAGCombiner
>
> I am working on some debug problems that we are seeing with the x86 
> backend and OpenCL.
>
> The input is linked.bc. There are three debug values, ip, tid and gid.
>
> llc -march=x86 linked.bc -o linked-x86.s <-- assembly file has all 
> three values in the debug info section
>
> However, if I attempt to optimize the bitcode with the following command:
>
> opt -disable-opt -inline-all -mem2reg linked.bc -o optimized.bc
>
> llc -march=x86 optimized.bc -o optimized-x86.s <-- Assembly file only 
> has ip and gid in the debug info section.
>
> Any idea on how to get this to work? I've attached the output, which 
> is missing the 'tid' debug variable.
>
> Thanks,
>
> Micah
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110414/1e8c4100/attachment.html>

Relph, Richard

2011-Apr-15 15:42 UTC

head link

[LLVMdev] Valid debug information being deleted by DAGCombiner

John,
    Mem2reg actually modifies debug information in a way that at least suggests
it's trying to maintain debugability. Specifically, it changes
llvm.dbg.declare() calls (appropriate for variables that permanently reside in a
single place) to llvm.dbg.value() calls (specifying that at this instant, this
variable is in this register).
    In fact, the .bc after inlining and mem2reg optimizations seems correct.
Llvm.dbg.value() refers to a chain of single-input phi nodes left behind by
inlining that ultimately resolve to the value in the inlined function that
corresponds to the return value. But when code gen does its thing, DAGCombiner
thinks some of the llvm.dbg.value() calls are associated with dead assignments
and removes them. Only we haven't been able to figure out why DAGCombiner is
sometimes confused. For example (from a slightly different test case than Micah
posted), here's a block of post-optimized IR for a dbg.value() call that the
DAGCombiner ends up deleting...

  %8 = extractelement <4 x i32> %7, i32 0         ; <i32> [#uses=1]
  br label %9

; <label>:9                                       ; preds =
%get_local_id.exit
  %10 = phi i32 [ %8, %get_local_id.exit ]        ; <i32> [#uses=1]
  br label %11

; <label>:11                                      ; preds = %9
  %12 = phi i32 [ %10, %9 ]                       ; <i32> [#uses=1]
  br label %get_global_id.exit

get_global_id.exit:                               ; preds = %11
  %13 = phi i32 [ %12, %11 ]                      ; <i32> [#uses=4]
  call void @llvm.dbg.value(metadata !{i32 %13}, i64 0, metadata !27), !dbg !28

    However, a similar sequence of IR 'works', IF that sequence's
analog to %13 is used in the SAME basic block as the assignment to %13. It's
only if %13 is not used in the same basic block that the dbg.value gets removed.
Or at least that's the feeling we have at this point.

Thanks,
Richard

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of John Criswell
Sent: Thursday, April 14, 2011 7:07 PM
To: Villmow, Micah
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Valid debug information being deleted by DAGCombiner

On 4/14/11 8:22 PM, Villmow, Micah wrote:
Found another bitcode file where a debug symbol is being dropped.

In the attached bitcode file, the variable gid is not in the debug output.

Dumb question: Have you looked to see if mem2reg is destroying (or not
maintaining) the debug information of interest (or put another way, was the
variable gid promoted to an LLVM register and therefore had its debug
information destroyed)?

I haven't used LLVM's new debug facilities, so my knowledge is out of
date, but I think optimizations are still permitted to remove debug info.

-- John T.



From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow,
Micah
Sent: Thursday, April 14, 2011 5:31 PM
To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: [LLVMdev] Valid debug information being deleted by DAGCombiner

I am working on some debug problems that we are seeing with the x86 backend and
OpenCL.

The input is linked.bc. There are three debug values, ip, tid and gid.


llc -march=x86 linked.bc -o linked-x86.s <-- assembly file has all three
values in the debug info section

However, if I attempt to optimize the bitcode with the following command:
opt -disable-opt -inline-all -mem2reg linked.bc -o optimized.bc
llc -march=x86 optimized.bc -o optimized-x86.s <-- Assembly file only has ip
and gid in the debug info section.


Any idea on how to get this to work? I've attached the output, which is
missing the 'tid' debug variable.

Thanks,
Micah






_______________________________________________

LLVM Developers mailing list

LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu

http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110415/5f14ef7f/attachment.html>

Villmow, Micah

2011-Apr-15 21:21 UTC

head link

[LLVMdev] Valid debug information being deleted by DAGCombiner

John/Richard,
I think I have found the problem to why the debug information is getting
destroyed. The problem is in SelectionDAG and how it interacts with the
SDDbgValue nodes and custom SDNodes.

When the dbg_value intrinsic is encountered, it adds the debug value to a
specific SD Node in SelectionDAGBuilder.cpp::visitIntrinsicCall(). In one of my
cases, it is vector_extract_elt.

During ISelLowering, the vector_extract_elt instruction is lowered to a custom
backend SDNode and all of the operands are transferred over. The SDNode that
stored vector_extract_elt is then deleted as it has no more uses. This then
invalidates the debug information, causing it to no longer be printed. As the
new SDNode has a debug loc, but not a corresponding SDDbgValue, it correctly
shows dbg:<filename>:line:col when printing the DAG, but not during
assembly printing.

So, now that I've figured out what the problem is, anyone have an idea on
how to fix it? Should getNode create a new SDDbgValue from a DebugLoc everytime?
Should the DAG update the SDDbgValue to point to a new node when getNode is
created?

Any other ideas?

Thanks,
Micah


From: Relph, Richard
Sent: Friday, April 15, 2011 8:42 AM
To: John Criswell; Villmow, Micah
Cc: llvmdev at cs.uiuc.edu
Subject: RE: [LLVMdev] Valid debug information being deleted by DAGCombiner

John,
    Mem2reg actually modifies debug information in a way that at least suggests
it's trying to maintain debugability. Specifically, it changes
llvm.dbg.declare() calls (appropriate for variables that permanently reside in a
single place) to llvm.dbg.value() calls (specifying that at this instant, this
variable is in this register).
    In fact, the .bc after inlining and mem2reg optimizations seems correct.
Llvm.dbg.value() refers to a chain of single-input phi nodes left behind by
inlining that ultimately resolve to the value in the inlined function that
corresponds to the return value. But when code gen does its thing, DAGCombiner
thinks some of the llvm.dbg.value() calls are associated with dead assignments
and removes them. Only we haven't been able to figure out why DAGCombiner is
sometimes confused. For example (from a slightly different test case than Micah
posted), here's a block of post-optimized IR for a dbg.value() call that the
DAGCombiner ends up deleting...

  %8 = extractelement <4 x i32> %7, i32 0         ; <i32> [#uses=1]
  br label %9

; <label>:9                                       ; preds =
%get_local_id.exit
  %10 = phi i32 [ %8, %get_local_id.exit ]        ; <i32> [#uses=1]
  br label %11

; <label>:11                                      ; preds = %9
  %12 = phi i32 [ %10, %9 ]                       ; <i32> [#uses=1]
  br label %get_global_id.exit

get_global_id.exit:                               ; preds = %11
  %13 = phi i32 [ %12, %11 ]                      ; <i32> [#uses=4]
  call void @llvm.dbg.value(metadata !{i32 %13}, i64 0, metadata !27), !dbg !28

    However, a similar sequence of IR 'works', IF that sequence's
analog to %13 is used in the SAME basic block as the assignment to %13. It's
only if %13 is not used in the same basic block that the dbg.value gets removed.
Or at least that's the feeling we have at this point.

Thanks,
Richard

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of John Criswell
Sent: Thursday, April 14, 2011 7:07 PM
To: Villmow, Micah
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Valid debug information being deleted by DAGCombiner

On 4/14/11 8:22 PM, Villmow, Micah wrote:
Found another bitcode file where a debug symbol is being dropped.

In the attached bitcode file, the variable gid is not in the debug output.

Dumb question: Have you looked to see if mem2reg is destroying (or not
maintaining) the debug information of interest (or put another way, was the
variable gid promoted to an LLVM register and therefore had its debug
information destroyed)?

I haven't used LLVM's new debug facilities, so my knowledge is out of
date, but I think optimizations are still permitted to remove debug info.

-- John T.


From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow,
Micah
Sent: Thursday, April 14, 2011 5:31 PM
To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: [LLVMdev] Valid debug information being deleted by DAGCombiner

I am working on some debug problems that we are seeing with the x86 backend and
OpenCL.

The input is linked.bc. There are three debug values, ip, tid and gid.


llc -march=x86 linked.bc -o linked-x86.s <-- assembly file has all three
values in the debug info section

However, if I attempt to optimize the bitcode with the following command:
opt -disable-opt -inline-all -mem2reg linked.bc -o optimized.bc
llc -march=x86 optimized.bc -o optimized-x86.s <-- Assembly file only has ip
and gid in the debug info section.


Any idea on how to get this to work? I've attached the output, which is
missing the 'tid' debug variable.

Thanks,
Micah






_______________________________________________

LLVM Developers mailing list

LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu

http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110415/52f2cbb9/attachment.html>

Maybe Matching Threads

Search for more maybe matching threads

llvm dev - Apr 2011 - [LLVMdev] Valid debug information being deleted by DAGCombiner

[LLVMdev] Valid debug information being deleted by DAGCombiner

[LLVMdev] Valid debug information being deleted by DAGCombiner

[LLVMdev] Valid debug information being deleted by DAGCombiner

Maybe Matching Threads