RetroSearch Browse

Wed Jul 8 13:34:39 PDT 2020 · https://lists.llvm.org/pipermail/llvm-dev/2020-July/143216.html

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 <dblaikie at gmail.com> wrote:

>
>
> On Wed, Jul 8, 2020 at 12:57 PM Shishir V Jessu <shishir.jessu at 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 <dblaikie at 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-dev at 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
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://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/20200708/e4c3aca3/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://lists.llvm.org/pipermail/llvm-dev/2020-July/143216.html below:

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