[llvm-dev] Extracting the !dbg property from LLVM IR function calls

[Shishir V Jessu via llvm-dev]

Hello, 

I am compiling a program with debugging information, and am attempting to extract !dbg numbers from function calls in LLVM IR. However, I've found a few inconsistencies. For example, this call exists in my module: 

%1 = tail call i1 @llvm.type.test(i8* bitcast (i32 (i32)* @_Z5otheri to i8*), metadata !"_ZTSFiiE") #5, !dbg !69, !nosanitize !2

I would like to extract the 69 from this line in my LLVM pass, but when I dump() the corresponding CallInst, I see the following: 

%1 = tail call i1 @llvm.type.test(i8* bitcast (i32 (i32)* @_Z5otheri to i8*), metadata !"_ZTSFiiE") #5, !dbg !29, !nosanitize !2

And finally, the line CallInst -> getDebugLoc() -> getLine() returns 61 for this call, not 69 or 29.

Am I misunderstanding the purpose of getDebugLoc() for a CallInst? Is there any way I can extract the correct !dbg for a given line? Thanks for your help!

Best, 
Shishir Jessu

[David Blaikie via llvm-dev]

The !69 and !29 refer to metadata (look further down in the LLVM IR dump) that looks something like this:

!10 = !DILocation(line: 3, column: 3, scope: !7)

Which is where the 'line' value is stored (so the line is not 69 or 29).

When you extract the function, only the referenced metadata is brought with it, so it gets renumbered - but the semantics remain the same - the line/column/scope is preserved. It's just there's fewer metadata nodes, so the metadata node number is smaller.

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[Shishir V Jessu via llvm-dev]

Hi David, 

Broader: Why do you want to know the relative order of calls in IR? That property isn't especially meaningful - for instance if the calls are in different basic blocks, then it's /really/ arbitrary, as the order of basic blocks shouldn't be significant.

Upon re-examining, I think what I really need is the order in which calls take place in the original source code - even if those calls are inlined. I see the DILocation has an InlinedAt field, which seems to be giving me the proper ordering for the code I'm looking at. I'll play around a bit more with it but I think that should give me what I need. Thanks for your help!

Best, 
Shishir Jessu

On Wed, Jul 8, 2020 at 3:08 PM David Blaikie <dbla...@gmail.com> wrote:

On Wed, Jul 8, 2020 at 12:57 PM Shishir V Jessu <shishi...@utexas.edu> wrote:

Hi David, 

Thanks for the quick response! I see now what's going on. 

My main issue here is that I want to sort a few CallInst objects by the order in which they appear in the IR.

Once you're dealing with LLVM IR in-memory (llvm::Module and associated classes) - I don't think that information exists, really? I guess it exists in some sense, because when the IR is dumped, it's printed in some order - I guess you'd find that order by iterating over basic blocks and instructions and you could "number" instructions that way (make a map from Instruction* to order number) and then sort via that table?
 

But here, I have a CallInst with !dbg=69 and line number 61, and a CallInst appearing further down in the program with !dbg=87, but its line number is 50.

Yeah, that line number doesn't have anything to do with the order of instructions in the IR - it's the source line from the original code (probably C++ from Clang, for instance).
 

Thus, my attempt to sort by line number isn't working, although as far as I can tell, the code hasn't actually been rearranged. This is compiled on -O2 with some inlining taking place, however, which may be leading to problems.

Yep. eg:

1: void f1();
2: void f2() {
3:   f1();
4: }
5: void f3() {
6:   f1();
7:   f2();
8: }

if f2 is inlined into f3, then you'll have two calls to f1, the first call is from line 6, the second is from line 3.
 

Is there any way you know of to sort these in the order in which they appear in the IR? Thanks for your help!

Broader: Why do you want to know the relative order of calls in IR? That property isn't especially meaningful - for instance if the calls are in different basic blocks, then it's /really/ arbitrary, as the order of basic blocks shouldn't be significant.
 

Best, 
Shishir

On Wed, Jul 8, 2020 at 1:30 PM David Blaikie <dbla...@gmail.com> wrote:

The !69 and !29 refer to metadata (look further down in the LLVM IR dump) that looks something like this:

!10 = !DILocation(line: 3, column: 3, scope: !7)

Which is where the 'line' value is stored (so the line is not 69 or 29).

When you extract the function, only the referenced metadata is brought with it, so it gets renumbered - but the semantics remain the same - the line/column/scope is preserved. It's just there's fewer metadata nodes, so the metadata node number is smaller.

On Wed, Jul 8, 2020 at 11:23 AM Shishir V Jessu via llvm-dev <llvm...@lists.llvm.org> wrote:

Hello, 

I am compiling a program with debugging information, and am attempting to extract !dbg numbers from function calls in LLVM IR. However, I've found a few inconsistencies. For example, this call exists in my module: 

%1 = tail call i1 @llvm.type.test(i8* bitcast (i32 (i32)* @_Z5otheri to i8*), metadata !"_ZTSFiiE") #5, !dbg !69, !nosanitize !2

I would like to extract the 69 from this line in my LLVM pass, but when I dump() the corresponding CallInst, I see the following: 

%1 = tail call i1 @llvm.type.test(i8* bitcast (i32 (i32)* @_Z5otheri to i8*), metadata !"_ZTSFiiE") #5, !dbg !29, !nosanitize !2

And finally, the line CallInst -> getDebugLoc() -> getLine() returns 61 for this call, not 69 or 29.

Am I misunderstanding the purpose of getDebugLoc() for a CallInst? Is there any way I can extract the correct !dbg for a given line? Thanks for your help!

Best, 
Shishir Jessu