Gaier, Bjoern via llvm-dev
2019-Jun-19 08:03 UTC
[llvm-dev] Questions about moving from MCJIT to Orc JIT
Hello LLVM-Mailing list, in the past I was using the MCJIT (if I understand it correctly) to load IR modules, compile them and execute them. The speciality of this JIT was, that it was writing the compiled code into a shared memory - for a different process to execute them. For that task the JIT used a 'custom' memory manager, memory mapping and also resolved undefined references itself. I was told some month ago, that MCJIT is heavily outdated and that I should move on to Orc JIT. So I did this today by reading the first Kaleidoscope Tutorial. Of course, I'm far away from having an understanding about the Orc JIT but I already miss all of the features I need to port my old JIT to the Orc JIT. So I did some research and have some questions now: 1.) Memory Manager I saw that I can actually replace the Memory Manager via the constructor of the "RTDyldObjectLinkingLayer" - is that correct? 2.) JITDyLib I think, but I'm not sure, that I can use a JITDyLib to inject my own addresses for different functions, but I'm not sure how to do that - or if I'm correct with it. 3.) Legacy Layer I later looked into the third Kaleidoscope Tutorial, seeing the "LegacyRTDyldObjectLinkingLayer" and "LegacyIRCompileLayer" - that looked promising! But sadly the tutorial state that it was not updated yet to the new OrcJIT API - so... I have difficulties 'trusting' that tutorial. Does it mean, that those Legacy Layer will be removed soon? Or that you should not use them? The term legacy worries me actually. 4.) Reusing the JIT With the MCJIT I noticed that you can not simply 'reset' the JIT and re-run it for a new compilation. What I mean with that is, I wanted to compile a IR module and then reset the MCJIT like it never compiled anything, so that I can set it up again, while not having to free the memory I already allocated. Is something possible with the Orc JIT? Thank you for your help in advance! Kind greetings 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, Takeshi Fukushima. Junichi Tajika -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190619/368c19fb/attachment.html>
Gaier, Bjoern via llvm-dev
2019-Jun-27 05:37 UTC
[llvm-dev] Questions about moving from MCJIT to Orc JIT
I apologize for the "push" on this subject - but can nobody say something to this? From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Gaier, Bjoern via llvm-dev Sent: Mittwoch, 19. Juni 2019 10:03 To: llvm-dev <llvm-dev at lists.llvm.org> Subject: [llvm-dev] Questions about moving from MCJIT to Orc JIT Hello LLVM-Mailing list, in the past I was using the MCJIT (if I understand it correctly) to load IR modules, compile them and execute them. The speciality of this JIT was, that it was writing the compiled code into a shared memory - for a different process to execute them. For that task the JIT used a 'custom' memory manager, memory mapping and also resolved undefined references itself. I was told some month ago, that MCJIT is heavily outdated and that I should move on to Orc JIT. So I did this today by reading the first Kaleidoscope Tutorial. Of course, I'm far away from having an understanding about the Orc JIT but I already miss all of the features I need to port my old JIT to the Orc JIT. So I did some research and have some questions now: 1.) Memory Manager I saw that I can actually replace the Memory Manager via the constructor of the "RTDyldObjectLinkingLayer" - is that correct? 2.) JITDyLib I think, but I'm not sure, that I can use a JITDyLib to inject my own addresses for different functions, but I'm not sure how to do that - or if I'm correct with it. 3.) Legacy Layer I later looked into the third Kaleidoscope Tutorial, seeing the "LegacyRTDyldObjectLinkingLayer" and "LegacyIRCompileLayer" - that looked promising! But sadly the tutorial state that it was not updated yet to the new OrcJIT API - so... I have difficulties 'trusting' that tutorial. Does it mean, that those Legacy Layer will be removed soon? Or that you should not use them? The term legacy worries me actually. 4.) Reusing the JIT With the MCJIT I noticed that you can not simply 'reset' the JIT and re-run it for a new compilation. What I mean with that is, I wanted to compile a IR module and then reset the MCJIT like it never compiled anything, so that I can set it up again, while not having to free the memory I already allocated. Is something possible with the Orc JIT? Thank you for your help in advance! Kind greetings 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, Takeshi Fukushima. Junichi Tajika 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, Takeshi Fukushima. Junichi Tajika -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/8683a2e3/attachment.html>
Praveen Velliengiri via llvm-dev
2019-Jun-27 06:21 UTC
[llvm-dev] Questions about moving from MCJIT to Orc JIT
Hi Bjoern, CC'ing Lang hames For questions, 1. In short yes, you can replace the memory manager, default one provided is section memory manager. 2. If you mean by " address of already compiled code", yes you can do that. Like this JITDylib.define(absoluteSymbols, ( Your_own_symbol , JITTargetAddress(Address of function))), now ORC can resolve all the references to Your_own_symbol to the provided the Address. 3. Yes, all the class/function with legacy prefix will be removed in subsequent releases. 4. Could please provide some more context on this? Like it's usage model, what goal you are aiming for? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/27748ecf/attachment.html>