similar to: [LLVMdev] mkpatch

I've included a patch which does not remove mkpatch but does remove diff search directories which caused a failure because those directories were no longer in svn. I was uncomfortable removing mkpatch since I believe it helps document creating patches for beginners who do not use separate source and build (object) root directories. Its existence is also expected by readers of:

[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

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

On Sun, Jan 10, 2010 at 12:38 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, > without the need for a module A dec to module B impl. mapping? > > Garrison Nope. You cannot place a call instruction into one module whose callee is a Function from another module. You

On Sat, Jul 23, 2011 at 2:36 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi Bill, > > Thanks for working on this. > > Is there a reference for the function attribute uwtable, or is it to be defined as > part of this effort? It already exists; there's some limited documentation in the LLVM source, but Rafael apparently forgot to add it to LangRef... -Eli

Here's the version of the unit test patch, incorporating the feedback I have received so far. Some notes on the patch: - This patch doesn't include googletest itself, that will need to be checked in separately. The source distribution will live in llvm/utils/unittest/googletest. (The reason for the extra directory level is so that the LLVM-specific makefiles can live in

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

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at

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 module behavior for all users of JIT. However this introduces some new semantics, and kind of circumvents the EngineBuilder API. More important though, I have not addressed any concern about using stub functions in eager

Hi James, Just wanted to update you. As you implied the problem here is that the personality function has to be jitted before the code that contains the corresponding llvm.eh.selector intrinsic instruction is jitted. I verified this by creating a generated version of the personality function which unless I jitted first, gave me the same error when running the code. Since you are using tools

Interesting. Was this the reason you were getting the recursive compilation error in JIT::runJITOnFunctionUnlocked(...) (isAlreadyCodeGenerating)? Do you have the time to try your test with 2.7? Garrison On Jan 22, 2010, at 17:37, James Williams wrote: > I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed

Several people on this list have reported issues with the linker regarding a named StructType instance with the same name in two different modules being resolved into two StructTypes with different names due to StructType:: setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). Nor do

2010/1/11 Garrison Venn <gvenn.cfe.dev at gmail.com> > I have not tried this, but a linkage type of PrivateLinkage would not add > to the symbol table according > to the doc. > > LLVMSetLinkage(g, LLVMPrivateLinkage); > Thanks - I hadn't thought of that. > > Garrison > > On Jan 11, 2010, at 14:03, James Williams wrote: > > 2010/1/11 Eli Friedman

Is it consistent to have a Pass instance's run method's implementation use getAnalysisIfAvailable<AnalysisType>() (vs just using getAnalysis< AnalysisType >) when that same instance's getAnalysisUsage(AnalysisUsage &au) implementation invokes au.addRequired<AnalysisType>()? For example in the implementation of SelectionDAGISel::runOnMachineFunction(...) (called

On 3 February 2010 14:13, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > I have not used the C api or the interpreter, but via JIT one can use > ExecutionEngine::addGlobalMapping(...) after the function decl in the > foreign module. See if there is an equivalent in the C API, which will > probably work for the interpreter given that this method is declared in >

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:

2008/12/30 Talin <viridia at gmail.com> > Here's the version of the unit test patch, incorporating the feedback I > have received so far. > Looks good, a few comments below. > Some notes on the patch: > > - This patch doesn't include googletest itself, that will need to be > checked in separately. The source distribution will live in >

2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Hi James, > > Note that the wiki example is a manual JIT example that works directly with > the C++ APIs. As you know, no LLVM tools are used, > just LLVM libraries. I say this to point out, that in the example, the > exception mechanism is under the complete control of the > developer moded by the LLVM libraries.

Hello, The 0.9.9 2.4.10pre4 patch doesn't apply. There are 5 rejects. The first three are easy to fix, but the fourth in vmscan.c will be very difficult without being a developer. The fifth I am not sure about. This brings up the fact that many of us are using ext3 and have to patch every time a new kernel comes out. I really think we need to strong arm Linus or something and get

Yes. The issue here, as you pointed out, is that your personality function is not called at all. Even if you did nothing in the personality function, associated with the setup caused by llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be called. Your results are acting like either dwarf exception header info is not emitted (llvm::DwarfExceptionHandling = true; not executed