[llvm-dev] Dangling debug value or bug in argument elimination pass?

Sergei Larin via llvm-dev llvm-dev at lists.llvm.org
Fri Apr 15 12:54:25 PDT 2016


> (do you have a specific example of where that comes up?)

 

Yes. If I use CloneFunctionInto on such scope, the hell breaks loose. At that point I have debug entries that are effectively dead and not being updated during cloning.

 

Unfortunately I do not yet have a clear test case that would show it on the public tree…  

 

Sergei

 

---

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

 

From: David Blaikie [mailto:dblaikie at gmail.com] 
Sent: Friday, April 15, 2016 2:38 PM
To: Sergei Larin <slarin at codeaurora.org>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Dangling debug value or bug in argument elimination pass?

 

Unclear. It's going to be awkward for debug info regardless (describing the variable is important to name lookup, describing the parameter's more important just so the user can at least see it's optimized out - but could break the ability to invoke the function (because the debugger may use all the function parameters to figure out the ABI, even if the parameter doesn't have a location description))

Certainly we shouldn't create stuff that the verifier thinks is bad (do you have a specific example of where that comes up?) but I don't know whether the fix is in the creation, the verifier, or both.

 

On Fri, Apr 15, 2016 at 11:56 AM, Sergei Larin via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote:

 

I will start from afar… When a dead function argument is removed, should we keep around the debug info for it?

 

I have the following case:

 

define internal fastcc void @foo(i8* %aa, i8* %reg, i8* %field, i32 %bb, ...) unnamed_addr #3 !dbg !28 {

entry:

  call void @llvm.dbg.value(metabb i8* %aa, i64 0, metabb !34, metabb !47), !dbg !57

  call void @llvm.dbg.value(metabb i8* %reg, i64 0, metabb !35, metabb !47), !dbg !58

  call void @llvm.dbg.value(metabb i8* %field, i64 0, metabb !36, metabb !47), !dbg !59

  call void @llvm.dbg.value(metabb i32 %bb, i64 0, metabb !37, metabb !47), !dbg !60

 

During dead argument elimination pass, some of the arguments are found “dead” (which they are) and removed, without removing  their correspondent llvm.dbg.value:

 

...

DAE - Removing argument 1 (reg) from foo

DAE - Removing argument 2 (field) from foo

...

…

 

define internal fastcc void @foo(i8* %aa, i32 %bb, ...) unnamed_addr #3 !dbg !28 {

entry:

  call void @llvm.dbg.value(metabb !2, i64 0, metabb !34, metabb !47), !dbg !57

  call void @llvm.dbg.value(metabb i8* null, i64 0, metabb !35, metabb !47), !dbg !58

  call void @llvm.dbg.value(metabb i8* null, i64 0, metabb !36, metabb !47), !dbg !59

  call void @llvm.dbg.value(metabb !2, i64 0, metabb !37, metabb !47), !dbg !60

 

>From that point on we carry dead debug info and correspondent metadata (DILocalVariable):

 

!33 = !{!34, !35, !36, !37, ...}

!34 = !DILocalVariable(name: "aa", arg: 1, scope: !28, file: !11, line: 90, type: !14)

!35 = !DILocalVariable(name: "reg", arg: 2, scope: !28, file: !11, line: 90, type: !31)

!36 = !DILocalVariable(name: "field", arg: 3, scope: !28, file: !11, line: 90, type: !31)

!37 = !DILocalVariable(name: "bb", arg: 4, scope: !28, file: !11, line: 90, type: !6)

 

In some instances it is wasteful but harmless, in others verifier is extremely unhappy about it.

 

The question is:

1)      Should llvm.dbg.value for dead argument has been deleted?

2)      Should DILocalVariable has been deleted?

 

Thanks…

 

 

Sergei

 

---

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

 


_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> 
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160415/69b2aa31/attachment.html>


More information about the llvm-dev mailing list