Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] MCJIT or ORC JIT for new project?"
2016 Nov 16
2
MCJit and remove module memory leak?
Hi Kevin, Koffie,
We will start migrating to ORC for next release, but for now, this release
> invoke delete after remove right?
MCJIT's removeModule method does not delete the module. You'll need to do
that manually. OrcMCJITReplacement is a bug-for-bug compatible
implementation of MCJIT using ORC components, so it does not free the
memory either.
Does this mean MCJIT is
2019 Jun 19
2
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.
2016 Oct 28
4
MCJit and remove module memory leak?
I'm on llvm 3.8.1 and was wondering if there's a memory leak in the
removeModule impl of mcjit.
In the tutorial http://llvm.org/releases/3.8.1/docs/tutorial/LangImpl4.html
a module is removed from the Jit by invoking removeModule.
According to the tutorial:
"Its API is very simple:: addModule adds an LLVM IR module to the JIT,
making its functions available for execution;
2019 Jun 27
2
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
2015 Mar 13
4
[LLVMdev] Thoughts about ExecutionEngine/MCJIT interface
Hi,
I think ExecutionEngine as a common interface for both Interpreter and
MCJIT is almost useless in the current form. There are separated methods in
ExecutionEngine for similar or the same features provided by Interpreter
and MCJIT, i.e. to get a pointer to function you should call
getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT.
Personally, I'm using MCJIT and
2016 Mar 29
0
MCJIT versus Orc
Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes:
> When writing a JIT compiler using LLVM, as I understand it, you can use two
> alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would
> it be accurate to say that if you want eager compilation - always compile
> an entire module upfront - you should use MCJIT?
+lang.
My understanding is that
2019 Jun 27
2
Questions about moving from MCJIT to Orc JIT
Nice!
Let me try to answer some questions,
Before that I have to mention this is ORC version 2 APIs and this is where
the project is moving forward.
JITDylib is the symbol table, basically for a JIT Symbol it have an
associated materializers, (you can think of it like an entity that generate
the address for that symbol),
Example: compiler are materializers.
So to add symbols to your own JIT you
2016 Mar 29
2
MCJIT versus Orc
When writing a JIT compiler using LLVM, as I understand it, you can use two
alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would
it be accurate to say that if you want eager compilation - always compile
an entire module upfront - you should use MCJIT?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2016 Mar 29
1
MCJIT versus Orc
Right, but is there any known use case where Orc's flexibility allows
something to be done that couldn't be with MCJIT, apart from lazy
compilation?
On Wed, Mar 30, 2016 at 12:19 AM, Justin Bogner <mail at justinbogner.com>
wrote:
> Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes:
> > When writing a JIT compiler using LLVM, as I understand it, you
2015 Feb 10
3
[LLVMdev] Some basic questions regarding MCJIT and Kaleidoscope sample
Hi,
I am building a new JIT compiler for Lua (actually a derivative of
Lua), and am planning to use LLVM for this. I have trying out some
basic functions using LLVM 3.5.1. I have been puzzled by one aspect of
the MCJIT versions of the Kaleidoscope sample, and would hugely
appreciate some insight.
Can a single MCJIT instance be used to manage several modules?
Why is a separate MCJIT instance
2017 Sep 22
2
Some questions regarding ORC JIT apis
Hi,
I am looking to port my MCJIT based implementation to ORC. I have been
reading up on the ORC tutorials, but am not clear on how to do
following:
I would like to discard everything other than the compiled code after
compiling a module.
A module may have more than one function in it - so I would like to
retain all the compiled functions.
I am okay with eager compilation - i.e. there is no need
2015 Feb 10
2
[LLVMdev] Some basic questions regarding MCJIT and Kaleidoscope sample
HI Dibyendu,
A single MCJIT instance can notionally manage multiple modules, but there
are caveats (which I'm afraid I don't remember off the top of my head) that
make it unattractive in practice. I believe most clients opt for something
like the ExecutionEngine-per-Module model used in the Kaleidoscope
tutorials.
As Dave mentioned, I'm also working on some new JIT APIs (Orc) that
2017 Nov 06
3
ORC JIT and multithreading
2017 Sep 23
0
Some questions regarding ORC JIT apis
Hi,
On 22 September 2017 at 15:33, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote:
> I am looking to port my MCJIT based implementation to ORC. I have been
> reading up on the ORC tutorials, but am not clear on how to do
> following:
>
> I would like to discard everything other than the compiled code after
> compiling a module.
> A module may have more than one
2016 Jul 29
2
Memory usage with MCJit
Hi Koffie,
I'd highly recommend switching to ORC from MCJIT. It is much more flexible
when it comes to memory-management.
1. I took the approach of 1 execution engine with multiple modules (I'm not
> removing modules once they have been added). During profiling, I noticed
> that the memory usage is high with a lot of code. How can I reduce the
> memory usage? Is one execution
2016 May 19
2
External function resolution: MCJIT vs ORC JIT
Thanks so much! This seems to do the trick. I would have spun my wheels for a long time before discovering all of this, wow.
Do I even want to know what additional chickens need to be sacrificed to get this to work on Windows?
-- lg
> On May 18, 2016, at 1:52 PM, Lang Hames <lhames at gmail.com> wrote:
>
> Hi Larry,
>
> You're basically there, but you're hitting
2015 Apr 21
2
[LLVMdev] Function calls only being JIT'd once by Kaleidoscope with MCJIT?
On Tue, Apr 21, 2015 at 7:26 AM, Per Mildner <Per.Mildner at sics.se> wrote:
> Charlie Turner <charlesturner7c5 <at> gmail.com> writes:
>
> > I was planning on committing these changes with the corresponding
> > changes to the Kaleidoscope tutorial walk-through. Might be a bit of a
> > surprise to have no explanation of what MCJITHelper and friends is
2016 May 20
0
External function resolution: MCJIT vs ORC JIT
Hi Larry,
Thanks so much! This seems to do the trick. I would have spun my wheels for
> a long time before discovering all of this, wow.
No worries. :)
I'll try to keep this in mind and make sure I address it in future
Kaleidoscope tutorial chapters - these issues tripped me up the first time
I encountered them too.
Do I even want to know what additional chickens need to be sacrificed
2015 Jan 14
3
[LLVMdev] New JIT APIs
Hi Philip,
In terms of the overall idea, I like what your proposing. However, I want
> to be very clear: you are not planning on removing any functionality from
> the existing (fairly low level) MCJIT interface right?
>
To confirm - I have no plans to remove MCJIT. I don't want to change any
behavior for existing clients. The new stuff is opt-in.
> We've built our own
2015 Apr 21
2
[LLVMdev] Function calls only being JIT'd once by Kaleidoscope with MCJIT?
On Tue, Apr 21, 2015 at 3:07 PM, Lang Hames <lhames at gmail.com> wrote:
> No progress since Charlie last looked at it.
Sorry, I meant to refer to the issue Per Mildner mentioned regarding
the tutorials not building due to RTTI - which I recall discussing
with you & Eric, but don't know what came of it.
> As Per suggested, it may be
> worth adding an explicit #error, or at