[llvm-dev] ORC JIT - Can modules independently managed with one LLJIT instance?
Gaier, Bjoern via llvm-dev
llvm-dev at lists.llvm.org
Thu Sep 17 23:59:47 PDT 2020
Hello everyone and Lang,
I have another design or "how-to" question about the ORC JIT. Sorry for having so many about them, to me this is a really complicated yet fascinating subject...
How would I design an ORC JIT with the following requirements?
At any time it should be possible to load a LLVM Module, every Module is independent and is not allowed to be linked with the other modules, every module can be removed at any time.
My first idea was to have an ORC JIT for every module I load, but then I wondered if I could use a single ORC JIT for it.
So, I would create an ORC JIT:
- using llvm::orc::LLJITBuilder
- configurating it
- adding a custom memory manager that requests the entire memory size
Then I would call "getMainJITDylib" and fill it with symbols that are valid for every module:
- adding printf, strlen, usw.
Now when I get a request to load a module:
- load module
- get symbols I want to look up
- create new DyLib and add module to that
Now I would do a lookup on that module, plus the main module to get symbol addresses and stuff
If a new module is added, it goes to a new DyLib as well and so on.
-----
However, now I want to delete a module again. Killing the memory is fairly easy with my custom memory manager, but I still have my DyLib of the now dead code... Can I get rid of it without dumping the others or the entire ORC JIT?
Or is there a different approach to do this? My goal with this is to speed up the setup phase for a module and also to reduce dynamic memory usage.
Also a related but different question:
When using llvm::parseIRFile I need to pass it a LLVMContext - should this be a unique one for every module I pass or can I use a global one?
Kind greetings and thank you all again,
Björn
Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Junichi Tajika, Ergin Cansiz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200918/e9ce7fe5/attachment.html>
More information about the llvm-dev
mailing list