similar to: [LLVMdev] fastcc and ExecutionEngine::getPointerToFunction()

Er... Sending this to the list instead of the parent... On Thu, Nov 19, 2009 at 4:49 AM, Hans Wennborg <hans at hanshq.net> wrote: > Yesterday I realised that if a Function has the calling convention set > to "fast", then it is a bad idea to call it through the function pointer > one gets from ExecutionEngine::getPointerToFunction(). > > The problem is that when

Hans Wennborg wrote: > Yesterday I realised that if a Function has the calling convention set > to "fast", then it is a bad idea to call it through the function pointer > one gets from ExecutionEngine::getPointerToFunction(). > > The problem is that when calling it from my C++ program, the call will > be made C-style, while the function expects to be called the fastcc

----- Original Message ---- > From: OvermindDL1 <overminddl1 at gmail.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Thu, November 19, 2009 6:12:47 AM > Subject: Re: [LLVMdev] fastcc and ExecutionEngine::getPointerToFunction() > > Er... Sending this to the list instead of the parent... > > On Thu, Nov 19, 2009 at 4:49 AM, Hans

On Nov 19, 2009, at 10:20 PM, Nick Lewycky wrote: > > Sure. You could be passing it in as a function pointer to another > function, that's planning to call it with fastcc calling convention. > > Or worse, you might be planning to call it with _stdcall (say, on > Windows) and discarding the calling convention would be actively harmful. > > In other words, please

On Thu, Nov 19, 2009 at 12:45 PM, Samuel Crow <samuraileumas at yahoo.com> wrote: > > > > > ----- Original Message ---- >> From: Kenneth Uildriks <kennethuil at gmail.com> >> To: Samuel Crow <samuraileumas at yahoo.com> >> Cc: OvermindDL1 <overminddl1 at gmail.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >> Sent:

----- Original Message ---- > From: Kenneth Uildriks <kennethuil at gmail.com> > To: Samuel Crow <samuraileumas at yahoo.com> > Cc: OvermindDL1 <overminddl1 at gmail.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Thu, November 19, 2009 12:22:55 PM > Subject: Re: [LLVMdev] fastcc and ExecutionEngine::getPointerToFunction() > > >

> I agree with you OvermindDL1, > > SInce the language I'm going to be working on doesn't support varargs, it would be nice to be able to ditch the C calling convention for fastcc in all occurrances for an added speed boost.  I also will need to add my own library calling convention on one platform I plan on supporting which will be register-loaded as well. Are you going to be

Two related questions. This is with LLVM 2.4 doing a JIT compile to x86-64. (I generate LLVM IR using an IRBuilder instance, compile/optimize, and then call getPointerToFunction() to get a "native" function pointer.) (1) My reading of various mailing list messages seems to indicate that a function marked as using the "fastcc" calling convention

Hi! I have this scenario: executionEngine->getPointerToFunction fails because a symbol can not be resolved. What can I do to catch this error? is an exception thrown? currently the program simply exits. returning NULL would be ok too. -Jochen

Given: typedef MyClass* (*jit_fn_ptr_type)(); MyClass* set_fn( llvm::Function *fn ) { // create an ExecutionEngine 'exec' ... jit_fn_ptr_type fn_ptr = (jit_fn_ptr_type)exec->getPointerToFunction( fn ); return fn_ptr(); } After I call getPointerToFunction() to obtain the pointer to the JIT'd function and fun the function (that will produce an instance of MyClass on the

Hi Paul, I'm surprised to hear that you aren't seeing any adverse effects. As I understand it, the memory for the function pointer returned by getPointerToFunction is owned by the JITMemoryManager which was used in creating the ExecutionEngine. In the case of the legacy JIT engine, the JITMemoryManager is owned by the JITEmitter which in turn is owned by the JIT ExecutionEngine. In the

Can you be more precise about where the error occurs? Depending on where it is, LLVM may or may not be able to propagate the error safely. Reid On Tue, Oct 26, 2010 at 4:05 PM, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote: > Hi! > > I have this scenario: > executionEngine->getPointerToFunction fails because a symbol can not be > resolved. > > What can I do to

Hi, Is this correct behaviour? test.ll: declare {} @__ex__print_int(i64) define i32 @main() { entry: %0 = call i64 @f.1() %1 = call {} @__ex__print_int(i64 %0) ret i32 0 } define internal fastcc i64 @f.1() { entry: ret i64 7 } > opt -std-compile-opts test.ll -S ; ModuleID = 'test.ll' define i32 @main() noreturn nounwind { entry: tail call void @llvm.trap()

On Wed, Apr 6, 2011 at 10:48 PM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi, > > Is this correct behaviour? > > test.ll: > > declare {} @__ex__print_int(i64) > > define i32 @main() { > entry: >  %0 = call i64 @f.1() >  %1 = call {} @__ex__print_int(i64 %0) >  ret i32 0 > } > > define internal fastcc i64 @f.1() { > entry: >

On Thu, Feb 12, 2009 at 5:34 PM, Jeff Kuskin <jk500500 at yahoo.com> wrote: > Two related questions. > (2) Why does the x86-64 JIT backend generate a "ret $0x8" instruction > to return from a fastcc function that is (a) marked as fastcc > (CallingConv::Fast); but (b) takes no arguments and returns 'void'? fastcc generated code ends with this: > c20800

On May 26, Reid Spencer wrote: > Alexander, > > Yes, a patch like that would be accepted. Fewer dependencies = good :) > > Some notes on doing this: > > (1) Please make sure you use the std c++ iostream libraries for doing > I/O. No native calls (we end up with portability problems). If you need > something that must be ported, please add it to lib/System Sure. What

On OSX I thought I'd try to optimize my compiler a bit by switching some of the calling conventions from CCallingConv to FastCC. The compiler ran fine, but when I executed the code, I got "Bad Instruction 4". I'm seeing some other mentions on this mailing list of issues like this on OSX (I'm using 10.8). Is there anything I need to change to enable fastcc with my compiler? I

Hello, While investigating one of the existing tests (test/CodeGen/X86/tailcallpic2.ll), I ran into IR that produces some interesting code. The IR is very straightforward: define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 %a4) { entry: ret i32 %a3 } define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { entry: %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %in2, i32

Hey Eli, On Thu, Feb 14, 2013 at 5:45 PM, Eli Bendersky <eliben at google.com> wrote: > Hello, > > While investigating one of the existing tests > (test/CodeGen/X86/tailcallpic2.ll), I ran into IR that produces some > interesting code. The IR is very straightforward: > > define protected fastcc i32 @tailcallee(i32 %a1, i32 %a2, i32 %a3, i32 > %a4) { > entry: >

Hi Arnold, Thanks for the insights. My comments below: On Thu, Feb 14, 2013 at 5:30 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > When you enable -tailcallopt you get support for tail calls between functions with arbitrary stack space requirements. That means the calling convention has to change slightly. E.g the callee is responsible for removing it's arguments of