search for: fastcc

...VM 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 ("CallingConv::Fast") cannot be called directly from GCC-generated code (n.b. -- standalone gcc, not llvm-gcc) because the fastcc calling convention is, in general, incompatible with GCC (which I assume uses the "CallingConv::C" calling convention). Cor...

...compiled without the flag >>> off >>> as stack behaviour would mismatch. >>> It would be no problem to make the behaviour dependent on the -tail- >>> call-opt flag. i am not sure that this is a good idea? >> >> In theory, any function can be marked fastcc. But llvm-gcc c / c++ >> frontend does *not* mark any external functions fastcc. > > The user can specify the "fastcall" and "stdcall" attributes, and it > looks > to me like llvm-gcc honors that. Certainly it should. This would imply one fastcc abi (callee p...

...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 way. > > Could LLVM either warn the user of this, or solve it for the user? > > One approach would be that getPointerToFunction() asserts that the > function has default calling convention. This way, the user would be > alerted. > > Another approach would be that if getPoint...

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() unreachable } declare void @llvm.trap() nounwind If I remove fastcc then everything works as expected. Does this...

On Fri, 5 Oct 2007, Arnold Schwaighofer wrote: >> to me like llvm-gcc honors that. Certainly it should. > > This would imply one fastcc abi (callee pops args on return) to rule > them all? > That is only if fastcall translates to llvm fastcc of course. fastcall != fastcc. fastcall is a well defined convention on x86 that has very specific ABI requirements. fastcc, on the other hand, is an LLVM thing, and LLVM is allowed...

...ldriks <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 >&g...

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 also tried the X86FastCCCalling...

----- 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 Wennborg wrote: > > Yesterday I realised that if a Function has the calling convention set > > to "fast", then it is...

...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: >  ret i64 7 > } > >> opt -std-compile-opts test.ll -S > > ; ModuleID = 'test.ll' > > define i32 @main() noreturn nounwind { > entry: >  tail call void @llvm.trap() >  unreachable > } > > declare void @llvm.trap() nounwin...

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 ret $0x8 > I assume the "ret 0x8" is meant to be the "callee pops args" portion > of the fastcc c...

>> 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 >> %in1, i32 %in2) &...

> 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 calling the JITted function from C++, or from your language? If the former, you'll need the...

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 %in1, i32 %in2) ret i32 %tmp11 } define i32 @foo(i32 %in1, i32 %in2) { entry: %q = call fastcc...

...uments of the stack. The caller cannot transitively know the tail callee's tailcallee's requirement. Also care must be taken to make sure the stack stays aligned. > Let me translate this to another phrasing to check my own understanding: w.r.t. foo calling talcaller. Since tailcaller is fastcc, when we generate code for it, we assume that the caller has allocated the required stack space, so it's safe to write "into the caller's frame". Even if it's not being "tail called" (like foo calls it, a normal call) the caller still has to guarantee this invariant....

On Oct 5, 2007, at 2:42 AM, Arnold Schwaighofer wrote: > Hi Evan, > I incoporated the changes you request but to the following i have got > a question: > >> Also, moving the option >> there will allow us to change fastcc ABI (callee popping arguments) >> only when this option is on. See Chris' email: > > I am not to sure on that. because that would make modules compiled > with the flag on incompatible with ones compiled without the flag off > as stack behaviour would mismatch. > It would be...

...14, 2013, at 4: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: > ret i32 %a3 > } > > define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { > entry: > %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %in2, i32 > %in1, i32 %in2) > ret i32 %tmp11 > } > > def...

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

Jeff Kuskin wrote: > Correct? If not, how do I call a LLVM JIT-generated fastcc function > from a function statically compiled by GCC? Well, you can always generate a little wrapper function with C calling convention which just calls the fastcc function. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag...

...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: > ret i32 %a3 > } > > define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { > entry: > %tmp11 = tail call fastcc i32 @tailcallee( i32 %in1, i32 %in2, i32 > %in1, i32 %in2) > ret i32 %tmp11 > } > >...

...he 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 way. Could LLVM either warn the user of this, or solve it for the user? One approach would be that getPointerToFunction() asserts that the function has default calling convention. This way, the user would be alerted. Another approach would be that if getPointerToFunction() detects that the fu...