similar to: [LLVMdev] updating module references in call instructions after a module clone

Forgot to CC the list. -- John t. -------- Original Message -------- Subject: Re: [LLVMdev] Fwd: updating module references in call instructions after a module clone Date: Thu, 06 Dec 2012 11:48:37 -0600 From: John Criswell <criswell at illinois.edu> Organization: University of Illinois To: charles quarra <charllsnotieneningunputocorreo at gmail.com> On 12/6/12 11:43 AM,

Hi, JIT does not allow functions to call others in different modules, so all modules need to be statically linked in a big fat module. If a module needs to be recompiled, all the others need to as well as relinked. there are two ways i intend to approach this problem: 1) forget about JITing, build each module into a .bc, call gcc to generate .soname libraries, dynamically load with dlopen()

What I was thinking is that if you need to link to module A to functions in module B (which you know might be re-JITed) you can have a stub function that gets used as the address called by module A and then you can use some brute force approach to maintain the actual address of the function in module B as it is re-JITed (maybe the stub could be a lightweight class with a member variable that's

2012/11/21 Kaylor, Andrew <andrew.kaylor at intel.com>: > If you re-JIT a module that you have previously linked to that will obviously cause some problems, but you can probably work around that with a stub function. could you elaborate a little bit on that ? i was thinking in something different; linking a cloned copy of the module rather than the module directly. Would that work

While improving ADCE, i notice that for declare i32 @strlen(i8*) readnone define i32 @test() { ; invoke of pure function should not be deleted! invoke i32 @strlen( i8* null ) readnone to label %Cont unwind label %Other ; <i32>:1 [#uses=0] Cont: ; preds = %0 ret i32 0 Other: ; preds = %0 %exn = landingpad {i8*, i32} personality i32 (...)* @__gxx_personality_v0

Hi Charles, Are you using the old JIT engine or the newer MCJIT? In either case, external functions are resolved through the getPointerToNamedFunction method in the JIT Memory Manager. If you provide your own memory manager implementation, you should be able to link multiple modules together. If you re-JIT a module that you have previously linked to that will obviously cause some problems, but

On Thu, May 17, 2018 at 1:24 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > On Thu, May 17, 2018 at 10:32 AM Xinliang David Li <xinliangli at gmail.com> > wrote: > >> >> >> On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Going to keep this RFC short and to the

On Thu, May 17, 2018 at 10:32 AM Xinliang David Li <xinliangli at gmail.com> wrote: > > > On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Going to keep this RFC short and to the point: >> >> TerminatorInst doesn't pull its weight in the type system. There is >> essentially a single

What is the difference between a CallInst and an InvokeInst in LLVM? Is an InvokeInst a CallInst that can throw an exception? Thanks, Ryan

I'm about to commit my changes to update the InvokeInst constructors to work like CallInst. Untill I get all of the llvm-gcc changes in, there will be a small window where llvm-gcc won't build. This shouldn't take more than 15-20 minutes depending on how fast subversion is. -Dave

> On May 17, 2018, at 2:03 AM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is essentially a single relevant API -- iterating successors. There is no other interesting aspect shared -- the interface itself just dispatches to

On Thu, May 17, 2018 at 2:03 AM, Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type system. There is > essentially a single relevant API -- iterating successors. There is no > other interesting aspect shared -- the interface itself just dispatches to

I had used dd to copy vm to hard drive . Once freenas runs on xen again i am thinking about exporting iscsi and using dd to make copies _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users

On Fri, May 18, 2018 at 10:26 PM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > On May 17, 2018, at 2:03 AM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Going to keep this RFC short and to the point: > > > > TerminatorInst doesn't pull its weight in the type system. There is >

Hi everyone, In order to have exceptions for non-call instructions (such as sdiv, load or stores), I'm modifying codegen so that it generates a BeginLabel and an EndLabel between the "may throwing" instruction. This is what the codegen of an InvokeInst does. However, when generating native code, only BeginLabel is generated, and it is generated after the instruction. I'm not

On Mon, 27 Aug 2007, David Greene wrote: > I'm about to commit my changes to update the InvokeInst constructors to work > like CallInst. Untill I get all of the llvm-gcc changes in, there will be a > small window where llvm-gcc won't build. This shouldn't take more than > 15-20 minutes depending on how fast subversion is. svn has atomic commits: can you commit both at

Hi all, Sorry for the inconvenient about the previous post. The files were not attached. So I put them here again. I am a newbie in LLVM and I am trying to replace the function like: old function || new function ============================== ========= int haha(int a) { int haha(int a, char* ID) { ===> }

+1, sounds like a great idea And if you're volunteering to do the work, even better! :) Philip p.s. Any reason we can't preserve a TerminatorInst type with an isa function which just returns true for all our terminators but without having terminators actually inherit from it?  If so, we preserve the bit of a "type safety" for a variable which is expected to always point to

Are there any instructions that aren't terminators now, but will become terminators with this change? I'm wondering if this is going to affect reading old bitcode, and if so, how it will be handled. -Krzysztof On 5/17/2018 4:03 AM, Chandler Carruth via llvm-dev wrote: > Going to keep this RFC short and to the point: > > TerminatorInst doesn't pull its weight in the type

On Sat, Mar 15, 2008 at 7:33 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > After some experimentation, I'd prefer the closed system. LLVM has some type > peculiarities like the commonality between CallInst and InvokeInst. I find > that the closed type system lets me express such constraints more naturally. > Expressing these constraints explicitly in the open