similar to: [LLVMdev] another experimental patch for bug 2606

Eek! I'm going to lose track of the threads if you start a new one every time you update the patch. Consider using http://codereview.appspot.com/? On Fri, Feb 26, 2010 at 5:44 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hey all, > Attached you will find an experimental patch which allows me to play with a > derived JIT class. With this patch > I've alleviated

FWIW, I don't like the idea of adding a new JIT class to support linking. I think you can do it without this. On Fri, Feb 26, 2010 at 5:44 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hey all, > Attached you will find an experimental patch which allows me to play with a > derived JIT class. With this patch > I've alleviated my concerns with forcing cross

No problem I'll drop this from our discussion as it really is only germane to my learning path and imagination. :-) I do at this time still have this concern of allowing a user (developer) the right to turn this "cross module linkage" off, but I'm still in the process of understanding your previous comments on this. Thanks again for the help and time by the way. Garrison PS:

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

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

[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 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

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

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

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

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

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 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

On Mon, Mar 1, 2010 at 4:52 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > I do have one question though. After having done the fix and the appropriate unit tests, > does one still need to add to the tests suite for the testing bots, and add to test for make > check (for this kind of bug fix)? Do the unittests somehow get invoked by make check? I > guess I don't

Hi Jeffrey, I'm still in the process of learning the unittest technology. While I did get distracted with test-suite and test, and therefore the requisite installs of llvm-gcc, and DejaGNU, I think I'm back on track now. So that was a waste of time. By the way the reference I have to the unittests target was in an archive for this list. Is there no llvm level doc for this? Regardless the

On Sat, Feb 27, 2010 at 2:25 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > No problem I'll drop this from our discussion as it really is only germane to my > learning path and imagination. :-) I do at this time still have this concern of > allowing a user (developer) the right to turn this "cross module linkage" off, but > I'm still in the process of

I ask for advice, for TheExecutionEngine === NULL, >> Which result's in a null-pointer for "TheExecutionEngine"; which >> explains the bus-errror .. Reid Kleckner wrote: > Try changing the above line to: > std::string str; > TheExecutionEngine = > EngineBuilder(OurModuleProvider).setErrorStr(str).create(); > cout << str << '\n';

Look at what is in <llvm source root>/examples/Kaleidoscope/toy.cpp. This is the final version of the tutorial and worked the last time I played with 2.6. Garrison On Jan 23, 2010, at 12:21, ALbert Mietus wrote: > I ask for advice, for TheExecutionEngine === NULL, > >>> Which result's in a null-pointer for "TheExecutionEngine"; which >>> explains

--Groetjes, Albert ALbert Mietus GSM: +316 16 531 258 Send prive mail to: ALbert at ons-huis dot net Don't send spam mail! Mijn missie: http://SoftwareBeterMaken.nl product, proces & imago. Mijn leven in het kort: http://albert.mietus.nl/Doc/CV_ALbert.html On 23 Jan 2010., at 22:07, Garrison Venn wrote: > Look

I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed before any unwind happens. -- James 2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > No, there is no magic. :-) > > To me though, the tools are magic, because I have no clue what they are > doing without looking at them and using them. >