Displaying 6 results from an estimated 6 matches for "isjit".
Did you mean:
isit
2010 Apr 17
0
[LLVMdev] Intro to the MC Project
...creates the JITObjectWriter. The
function which is registered to create AsmBackend
(createX86_32/64AsmBackend) needs to know if it should create a classical
(ELF, or Darwin/Macho) AsmBackend or a JIT one.
To discriminate, I see 2 possibilities :
- Add an argument to createAsmBackend functions (bool IsJIT ?)
- Set something specific to the JIT on the target triple. Currently I have a
"JIT" string in the environment part of the triple. (i686-pc-linux-gnu
becomes i686-pc-linux-JIT). As the target triple is easy to change, this is
currently the solution I use.
What do you think ? Do you see a...
2010 Apr 16
2
[LLVMdev] Intro to the MC Project
I do have an opinion, but don't have enough time to comment in much depth. The approximate approach I had in mind sounds like what you describe, though, the JITObjectWriter is the core piece, the other pieces probably fall into place as it becomes obvious if they are needed.
It should be pretty straightforward to bring up something which works for running code with no external symbols, if you
2009 Oct 30
2
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...ecute new code
jmp <nop nop nop nop nop nop nop nop> // will be patched
waitJIT:
jitLock()
jitUnlock()
^This should be consistent with the Intel Manual's requirements on XMC,
which has a similar algorithm, except for the fast-path.
CompilationCallBack:
jitLock();
if (isJITed(F)) {jitUnlock(); return;}
JIT function
patch_callsite(&patchsite, compiledFunctionAddress);
patch_callsite(&patchsite2, compiledFunctionAddress);
setJITed(F, true);
jitUnlock();
This way once it is compiled the callsite will only execute:...
2009 Nov 01
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
...op nop> // will be patched
>
> waitJIT:
> jitLock()
> jitUnlock()
>
> ^This should be consistent with the Intel Manual's requirements on XMC,
> which has a similar algorithm, except for the fast-path.
>
> CompilationCallBack:
> jitLock();
> if (isJITed(F)) {jitUnlock(); return;}
> JIT function
>
> patch_callsite(&patchsite, compiledFunctionAddress);
> patch_callsite(&patchsite2, compiledFunctionAddress);
> setJITed(F, true);
>
> jitUnlock();
>
> This way once it is compiled the ca...
2009 Oct 29
0
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray
<nicolas.geoffray at lip6.fr> wrote:
> Hi Jeffrey,
>
> Jeffrey Yasskin wrote:
>>
>> Cool, I'll start implementing it.
>>
>
> Great! Thanks.
>
> Just to clarify things: on my end, it doesn't really matter what is the
> default behavior, as long as vmkit can continue to have the existing
>
2009 Oct 29
3
[LLVMdev] Should LLVM JIT default to lazy or non-lazy?
Hi Jeffrey,
Jeffrey Yasskin wrote:
> Cool, I'll start implementing it.
>
Great! Thanks.
Just to clarify things: on my end, it doesn't really matter what is the
default behavior, as long as vmkit can continue to have the existing
behavior of lazy compilation. With Chris' solution, I was wondering how
you would implement the getPointerToFunction{Eager, Lazy} functions when