Hi Tim, Thank you very much for quick response. What happens in my case is that mixing calls to getOrInsertFunction with linking another bit code module to the current module seems to be sometimes producing different outputs. Difference might be with the ordering of functions in the file (I¹m looking at LLVM IR representation), with numbers used for constant variables, numbers used in the ³dbg² metadata. Since sometimes the diff is not trivial to analyse I just wasn¹t sure if I only get these sort of differences and not differences like actual instructions being reordered. Do you know what might be the cause of these differences? Thank you, Tomek On 29/05/2014 19:06, "Tim Northover" <t.p.northover at gmail.com> 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.
Hi Tomek, On 29 May 2014 19:12, Kuchta, Tomasz <t.kuchta12 at imperial.ac.uk> wrote:> Thank you very much for quick response. What happens in my case is that > mixing calls to getOrInsertFunction with linking another bit code module to > the current module seems to be sometimes producing different outputs.Even with exactly the same call sequence in each case? That's probably not intended. As you say, it makes looking for actual changes difficult; and for purely Clang-related reasons we want link-time optimized binaries to be comparable with "diff" to verify staging works. The usual cause of these issues is something being sorted by pointer or hash rather than name or some other prior order. I can't see any obvious data structures like that in llvm::Module though.> Difference might be with the ordering of functions in the file (I¹m > looking at LLVM IR representation), with numbers > used for constant variables, numbers used in the ³dbg² metadata.Do you mean you're not sure where the difference is there, or that you've seen all of those differences in practice? Cheers. Tim.
Hi Tim, On 29/05/2014 19:36, "Tim Northover" <t.p.northover at gmail.com> wrote:>Hi Tomek, > >On 29 May 2014 19:12, Kuchta, Tomasz <t.kuchta12 at imperial.ac.uk> wrote: >> Thank you very much for quick response. What happens in my case is that >> mixing calls to getOrInsertFunction with linking another bit code >>module to >> the current module seems to be sometimes producing different outputs. > >Even with exactly the same call sequence in each case? That's probably >not intended.Yes, that was for the same code base. However, as I mentioned in my e-mail to Philip, this might also be related to my outdated version of LLVM - I should check it on some newer one to make sure.> >As you say, it makes looking for actual changes difficult; and for >purely Clang-related reasons we want link-time optimized binaries to >be comparable with "diff" to verify staging works. > >The usual cause of these issues is something being sorted by pointer >or hash rather than name or some other prior order. I can't see any >obvious data structures like that in llvm::Module though. > >> Difference might be with the ordering of functions in the file (I¹m >> looking at LLVM IR representation), with numbers >> used for constant variables, numbers used in the ³dbg² metadata. > >Do you mean you're not sure where the difference is there, or that >you've seen all of those differences in practice?I’ve seen different naming for string constants and different ordering of functions in the LLVM IR.> >Cheers. > >Tim.Thanks a lot, Tomek