similar to: [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

In thinking about this we could use a Mutex::tryacquire(...) (non-recursive), around JIT::runJITOnFunctionUnlocked(...)'s while loop, and use your JITEmitter:: getLazyFunctionStub(...) suggestion in place of forceEmitFunctionStub(...). Is the lock attempt too heavy, even if it is implemented with atomics? I'll implement this when I have time. Garrison On Feb 17, 2010, at 15:42, Garrison

Hi Olivier, Thanks for responding! I get to learn this way. On Feb 17, 2010, at 12:50, Olivier Meurant wrote: > 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 we go further with this, I'll have to add test cases for lazy mode. I kind

[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

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

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

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

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

On Fri, Feb 26, 2010 at 1:26 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > 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

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 doing something that seems horribly wrong are welcome. I'll

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

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

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

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

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

Dear Contributors, I am asking help on the way how to solve a problem related to loops for that I always get confused with. I would like to perform the following procedure in a compact way. Consider that p is a matrix composed of 100 rows and three columns. I need to calculate the sum over some rows of each column separately, as follows: fa1<-(colSums(p[1:25,])) fa2<-(colSums(p[26:50,]))

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,

Hello: I am doing forward stepwise analysis on the glm model. I am trying to use model operator in the "upper" scope formula, for example, scope=list(lower=~1,upper=~ .^2) but the upper bound of the scope seems to be ignored and add1 is not performed at all, while if the terms are explicitly listed in the formula, the step function seems to work

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

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