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
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
Hi Philip, I would like to ask a follow-up question about code generation. Do you know if is expected that if we take the same bit code modules and link them together in the same order (programatically), but on different machines (assuming the same version of LLVM and roughly the same OS), the output may differ with respect to order of function definitions inside module? Thank you very much in advance for help, Best regards Tomasz Kuchta On 29/05/2014 22:22, "Kuchta, Tomasz" <t.kuchta12 at imperial.ac.uk> wrote:>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 >