[LLVMdev] Module::getOrInsertFunction determinism

Kuchta, Tomasz t.kuchta12 at imperial.ac.uk
Thu May 29 14:22:30 PDT 2014


Hi Philip,

Thank you very much for the reply. I need to add one important detail -
currently I¹m working on an outdated version of
LLVM, so I will need to first make sure that it also appears on the
current one. 

The use case that I have in mind is to be able to uniquely identify
instruction in the bit code.
For example let¹s say we have an ³add² instruction in some function and I
want to know that this is the same
instruction in two separate runs. If the function is put in some different
place as a result of inserting function and linking in the second run,
how would I identify that instruction? It seems to me that cannot rely on
the offset of the instruction within the binary and I cannot rely on the
instruction count.
The problem in my case was that for the same source code base, I was
getting different resulting LLVM IR when doing the same
sequence of getOrInsertFunction and linking with other bit code modules on
each of runs.

Thank you,
Tomek

On 29/05/2014 19:34, "Philip Reames" <listmail at philipreames.com> wrote:

>
>On 05/29/2014 11:06 AM, Tim Northover wrote:
>> Hi Tomek,
>>
>>> I¹ve got a question about Module::getOrInsertFunction().
>>> I got an impression that it is not deterministic where exactly in the
>>>bit
>>> code module the new function will be inserted.
>> Looking at the code (not exhaustively), it seems a new function will
>> always be added to the end of a module.
>>
>> Documenting that probably wouldn't be a terrible idea, but it
>> shouldn't affect anything except the human-readability of LLVM IR. Are
>> you trying to do something where it is actually causing problems?
>>
>> Cheers.
>>
>> Tim.
>I would argue in favor of leaving this explicitly undocumented.  I don't
>see the use case in knowing where in a module it got added, and it
>restricts future implementations in ways we can't predict. Documenting
>that it must be deterministic is fine.  Documenting where it decides to
>place it is not.
>
>Tomek, could you spell out why you need the position?  Maybe there's
>another option here.
>
>Philip
>_______________________________________________
>LLVM Developers mailing list
>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





More information about the llvm-dev mailing list