Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Control Flow and Locks when JITing Functions"
2005 Apr 21
0
[LLVMdev] Control Flow and Locks when JITing Functions
On Thu, 21 Apr 2005, Evan Jones wrote:
> I just located a concurrency error in my LLVM patch to add locks to the
> JIT. I did not add any locks to the JITResolver class in JITEmitter.cpp,
> which clearly is a problem since This particular issue causes an
> assertion failure on occasion when running a task that spawns threads on
> a parallel machine. Any recommendations about if I am
2005 Apr 21
1
[LLVMdev] Control Flow and Locks when JITing Functions
On Apr 21, 2005, at 12:12, Chris Lattner wrote:
> Ok. Thanks, for forgot about that patch :(
No problem, since I still don't know how to integrate it cleanly into
the build system. Platform dependencies are very annoying.
> I think it would be more straight-forward to have a single lock that
> the jit resolver can aquire. Makes sense to me at least
This is actually what I ended
2010 Feb 16
2
[LLVMdev] Work in progress patch to bug 2606
The patch I recently attached to bug 2606, reproduced here, is my first attempt to solve this issue
as represented by the attached test cases. To solve the foreign Module GlobalVariable problem,
I modified JIT::getOrEmitGlobalVariable(...) to directly attempt to map a found "external" GlobalVariable.
To solve the foreign Module Function problem, I modified both JIT.{h,cpp} and
2008 Aug 06
2
[LLVMdev] crash in JIT when running the inliner
Hi,
Today I've been trying to debug a weird bug that makes JIT crash with
certain code and when using the inliner. This may sound weird, but if I
disable the inliner, it doesn't crash.
I include an example gdb dump below. Does something looks wrong? Do you
think it's a bug in JIT or it's just some other piece of code that is
writing on the JIT memory?.. I don't really know
2010 Feb 07
3
[LLVMdev] Jit singleton
Hi Jeffrey,
Thanks for pointing me in the right direction !
I'm not using the JIT in lazy mode, but it was fun to understand the
lazy-stub code.
Attached you will find a patch which follow your 1st option : a map
Stub_address -> JITResolver instance, except that the used map is a
"std::map" to apply the same upper_bound trick as in the map
CallSiteToFunctionMap of the
2010 Feb 04
0
[LLVMdev] Jit singleton
In eager compilation mode, I don't know of anything that would go
wrong with having multiple JITs in the process. However, in lazy
compilation mode, we need to map stub addresses to the JIT that knows
how to compile them. Right now, that's done by looking up the static
"TheJITResolver" variable and assuming it's the only JIT, but we could
1) use a static
2010 Feb 10
0
[LLVMdev] Jit singleton
Thanks for the patch! I'll clean this up, convert your sample to a
unit test, and commit it for 2.7.
On Sun, Feb 7, 2010 at 6:09 AM, Olivier Meurant
<meurant.olivier at gmail.com> wrote:
> Hi Jeffrey,
>
> Thanks for pointing me in the right direction !
> I'm not using the JIT in lazy mode, but it was fun to understand the
> lazy-stub code.
>
> Attached you will
2010 Feb 10
1
[LLVMdev] Jit singleton
Thanks Jeffrey !
If possible, keep me inform (on revision number), I'm interested to see how
you will do the unit test. (For my future patch... :) ).
Thanks again.
Olivier.
On Wed, Feb 10, 2010 at 6:22 PM, Jeffrey Yasskin <jyasskin at google.com>wrote:
> Thanks for the patch! I'll clean this up, convert your sample to a
> unit test, and commit it for 2.7.
>
> On Sun,
2010 Feb 26
2
[LLVMdev] 2nd attempt for a working patch for bug 2606
Hi Olivier,
On Feb 25, 2010, at 14:10, Olivier Meurant wrote:
> Hi Garrison,
>
> I finally come back from holidays and take time to watch your patch.
>
> I must say that I largely prefer this version over the previous one ! I like the reuse of getLazyFunctionStub, but I don't know if the forceEmitFunctionStub is still needed ?
JIT::forceEmitFunctionStub(...) was created to
2010 Feb 17
0
[LLVMdev] Work in progress patch to bug 2606
Hi Garrison,
I am not a specialist of the code but here is my 2 cents:
- I like the idea that in lazy-mode the call (in module or not) is treated
by a stub (like every calls).
- If the jit is in non-lazy mode, I'm not really fan of the "stub" solution.
Is it not possible to use the same mechanism as it already exists : add the
function to pending list and emit it after the current
2010 Feb 04
2
[LLVMdev] Jit singleton
Hi everyone !
If I call ExecutionEngine::createJIT (or EngineBuilder::create) more than
one time, the second time fails on a assertion "Multiple JIT resolvers?".
It seems that the JIT is designed to be a singleton in the process, and I
was wondering if it was something mandatory.
How hard will it be to make it a non-singleton object ? Is this a JIT-only
problem (work needed on JIT
2005 Feb 20
3
[LLVMdev] HowToUseJIT: failed assertion on PPC/Mac OS X
I just got the CVS version of LLVM running tonight. On my PowerBook,
one of the examples (HowToUseJIT) has an assertion error when I try and
run it:
Running foo: JIT.cpp:217: failed assertion `!isAlreadyCodeGenerating &&
"Error: Recursive compilation detected!"'
However, when I compile and run the same program on x86 Linux, it runs
fine (Running foo: Result: 11). I
2010 Feb 26
1
[LLVMdev] 2nd attempt for a working patch for bug 2606
[sidenote: Please try to avoid extraneous whitespace and line wrapping
changes in your patches. It makes it harder to see what you're actually
changing]
On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote:
> Hi Olivier,
>
> On Feb 25, 2010, at 14:10, Olivier Meurant wrote:
>
> Hi Garrison,
>
> I finally come back from holidays and take
2010 Feb 26
0
[LLVMdev] 2nd attempt for a working patch for bug 2606
Hi Jeffrey,
On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote:
> [sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing]
Sorry just saw some preexisting code was not in 80 columns.
>
> On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote:
> Hi
2008 Aug 07
0
[LLVMdev] crash in JIT when running the inliner
Hi,
> Today I've been trying to debug a weird bug that makes JIT crash with
> certain code and when using the inliner. This may sound weird, but if I
> disable the inliner, it doesn't crash.
> I include an example gdb dump below. Does something looks wrong? Do you
> think it's a bug in JIT or it's just some other piece of code that is
> writing on the JIT
2008 Feb 04
0
[LLVMdev] Exception handling in JIT
Looks sane. Thanks.
Evan
On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote:
> Dear all,
>
> Here's a new patch with Evan's comments (thx Evan!) and some cleanups.
> Now the (duplicated) exception handling code is in a new file:
> lib/ExecutionEngine/JIT/JITDwarfEmitter.
>
> This patch should work on linux/x86 and linux/ppc (tested).
>
> Nicolas
> Index:
2010 Feb 25
0
[LLVMdev] 2nd attempt for a working patch for bug 2606
Hi Garrison,
I finally come back from holidays and take time to watch your patch.
I must say that I largely prefer this version over the previous one ! I like
the reuse of getLazyFunctionStub, but I don't know if the
forceEmitFunctionStub is still needed ?
I thought about JIT and modules, and I wonder if we don't need to take it
another way.
Now we can create multiples JIT. What if we
2010 Feb 19
3
[LLVMdev] 2nd attempt for a working patch for bug 2606
This is the second version of a patch, which I recently attached to bug 2606, whose original version was
modified to reflect the lists comments. Also please note the comment at the end of this email, which basically
questions whether this bug is really a bug.
1) To solve the foreign Module GlobalVariable problem, I modified JIT::getOrEmitGlobalVariable(...) to
directly attempt to map a found
2007 Dec 11
0
[LLVMdev] Exception handling in JIT
On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote:
> Hi everyone,
>
> Here's a patch that enables exception handling when jitting. I've
> copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may
> need
> to factorize it, but the functionality is there and I'm very happy
> with
> it :)
Very nice! I don't know enough about EH, someone else
2007 Dec 07
3
[LLVMdev] Calling functions defined in .o files in LLVM code executed in lli
Hi,
This is probably an easy question, but I could not find the answer to it.
I'm working on a LLVM back-end for the EHC compiler (a Haskell
compiler). Currently there is a C back-end and I would like to reuse the
primitive library functions from this back-end.
So I have compiled C sources in a .o file and I would like to call these
from my LLVM code. If I declare these primitive functions