Geoff Levner via llvm-dev
2018-Sep-12 10:09 UTC
[llvm-dev] dynamic namespacing of JIT modules?
Greetings, LLVM wizards! We have an application that uses Clang and Orc JIT to compile and execute C++ code on the fly. The JIT contains any number of LLVM modules, each of which defines a function, plus a "main" module that calls those functions. Several functions may have the same signature, so I need to find a way to resolve them. Originally, I just put each module's code in its own namespace when it was compiled. But now we want to be able to compile them separately to bitcode files and read them later. So at compilation time there is no longer any way to assign a unique namespace to each. I have a couple ideas for possible solutions, but I'm hoping some LLVM expert out there has a better one... 1. Assign each module a unique namespace when its bitcode is loaded: go through the IR and add the namespace to the names of the functions defined (and called, in the case of internal functions). I don't know how to do that. Perhaps somebody else does? 2. Assign each module a unique namespace, but don't change the modules themselves: just add the namespace when a function is called from the main module, and modify the JIT's symbol resolver to strip the namespace and look for the function only in the relevant module. Help...?
Andres Freund via llvm-dev
2018-Sep-12 19:48 UTC
[llvm-dev] dynamic namespacing of JIT modules?
Hi, On 2018-09-12 12:09:24 +0200, Geoff Levner via llvm-dev wrote:> Greetings, LLVM wizards!Not one of them...> We have an application that uses Clang and Orc JIT to compile and > execute C++ code on the fly. > > The JIT contains any number of LLVM modules, each of which defines a > function, plus a "main" module that calls those functions. Several > functions may have the same signature, so I need to find a way to > resolve them. > > Originally, I just put each module's code in its own namespace when it > was compiled. But now we want to be able to compile them separately to > bitcode files and read them later. So at compilation time there is no > longer any way to assign a unique namespace to each.Why not? If you assign a random uuid, or a sequential number of whatnot, that should work.> 2. Assign each module a unique namespace, but don't change the modules > themselves: just add the namespace when a function is called from the > main module, and modify the JIT's symbol resolver to strip the > namespace and look for the function only in the relevant module.That's kind of what I do for a similar-ish problem in the JIT engine in postgres (which uses orcjit). There multiple dynamically loaded extensions can register functions whose source code is available, and each of them can have conflicting symbols. The equivalent of your main module generates function names that encode information about which module to look for the actual definition of the function, and then does the symbol resolution outside of LLVMs code. I do that both when inlining these functions, and when generating funciton calls to the external function. Not sure if that helps. Greetings, Andres Freund
Alex Denisov via llvm-dev
2018-Sep-12 21:47 UTC
[llvm-dev] dynamic namespacing of JIT modules?
Not sure if I’ve got your question right. Do you want to “redirect” calls from the main module to different functions from different modules? It would help to understand the problem if you elaborate a bit. As of this one:> 1. Assign each module a unique namespace when its bitcode is loaded: > go through the IR and add the namespace to the names of the functions > defined (and called, in the case of internal functions). I don't know > how to do that. Perhaps somebody else does?you can simply iterate over all the functions and change their names, e.g.: function.setName(“foobar” + function.getName())> On 12. Sep 2018, at 12:09, Geoff Levner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Greetings, LLVM wizards! > > We have an application that uses Clang and Orc JIT to compile and > execute C++ code on the fly. > > The JIT contains any number of LLVM modules, each of which defines a > function, plus a "main" module that calls those functions. Several > functions may have the same signature, so I need to find a way to > resolve them. > > Originally, I just put each module's code in its own namespace when it > was compiled. But now we want to be able to compile them separately to > bitcode files and read them later. So at compilation time there is no > longer any way to assign a unique namespace to each. > > I have a couple ideas for possible solutions, but I'm hoping some LLVM > expert out there has a better one... > > 1. Assign each module a unique namespace when its bitcode is loaded: > go through the IR and add the namespace to the names of the functions > defined (and called, in the case of internal functions). I don't know > how to do that. Perhaps somebody else does? > > 2. Assign each module a unique namespace, but don't change the modules > themselves: just add the namespace when a function is called from the > main module, and modify the JIT's symbol resolver to strip the > namespace and look for the function only in the relevant module. > > Help...? > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 529 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180912/b3986e04/attachment.sig>
Geoff Levner via llvm-dev
2018-Sep-13 09:12 UTC
[llvm-dev] dynamic namespacing of JIT modules?
On Wed, 12 Sep 2018 at 21:48, Andres Freund <andres at anarazel.de> wrote:> > Hi, > > On 2018-09-12 12:09:24 +0200, Geoff Levner via llvm-dev wrote: > > Greetings, LLVM wizards! > > Not one of them... > > > > We have an application that uses Clang and Orc JIT to compile and > > execute C++ code on the fly. > > > > The JIT contains any number of LLVM modules, each of which defines a > > function, plus a "main" module that calls those functions. Several > > functions may have the same signature, so I need to find a way to > > resolve them. > > > > Originally, I just put each module's code in its own namespace when it > > was compiled. But now we want to be able to compile them separately to > > bitcode files and read them later. So at compilation time there is no > > longer any way to assign a unique namespace to each. > > Why not? If you assign a random uuid, or a sequential number of > whatnot, that should work.Yes, that is the solution I am looking into at the moment, actually: using a UUID to generate a namespace when the module is compiled. However, that means saving the UUID somewhere; the bitcode is no longer self-sufficient. I suppose I could create a special global variable in the module containing the UUID...> > 2. Assign each module a unique namespace, but don't change the modules > > themselves: just add the namespace when a function is called from the > > main module, and modify the JIT's symbol resolver to strip the > > namespace and look for the function only in the relevant module. > > That's kind of what I do for a similar-ish problem in the JIT engine in > postgres (which uses orcjit). There multiple dynamically loaded > extensions can register functions whose source code is available, and > each of them can have conflicting symbols. The equivalent of your main > module generates function names that encode information about which > module to look for the actual definition of the function, and then does > the symbol resolution outside of LLVMs code. I do that both when > inlining these functions, and when generating funciton calls to the > external function.I did try something like that. The problem I ran into is that the symbol resolver receives mangled function names. It is easy enough to demangle them there, but hard to mangle names before compiling. Once you have decoded your function name in the symbol resolver, how do you generate a mangled name for the actual function you want to resolve to?> Not sure if that helps. > > Greetings, > > Andres FreundThanks, Andres.
Reasonably Related Threads
- LLVM Developers Meeting JIT BoF -- Request for Topics of Interest
- LLVM Developers Meeting JIT BoF -- Request for Topics of Interest
- runStaticConstructorsDestructors() causes crash on exit
- runStaticConstructorsDestructors() causes crash on exit
- runStaticConstructorsDestructors() causes crash on exit