similar to: [LLVMdev] JIT + tail cals

Alexander Friedman wrote: > How do I tell the code generator to enable tail calls on the X86? > Since it is part of a library, I cannot pass a command line argument. Here is a snippet from our code which might help you ;-) const char *args[] = { "-disable-pattern-isel", "false", 0 }; cl::ParseCommandLineOptions(2, args); m.

On Wed, 18 May 2005, Morten Ofstad wrote: > Alexander Friedman wrote: >> How do I tell the code generator to enable tail calls on the X86? >> Since it is part of a library, I cannot pass a command line argument. > > Here is a snippet from our code which might help you ;-) > > const char *args[] = { "-disable-pattern-isel", "false", 0 }; >

Chris Lattner wrote: > On Wed, 18 May 2005, Chris Lattner wrote: > >> Yup, something like this should work. Two comments though: >> 2. I haven't done much testing with the JIT and tail calls. I >> wouldn't be >> suprised if there are minor issues that need to be fixed. I will try >> to take a look and see what remains to be done over the next

VC++ builds are working again. However, llvm-test is broken. The configured makefile is bad: # Path to the boxed-sim source code @USE_BOXEDSIM@ BOXEDSIM_ROOT := @BOXEDSIM_ROOT@ Jeff Cohen wrote: > Chris Lattner wrote: > >> On Wed, 18 May 2005, Chris Lattner wrote: >> >>> Yup, something like this should work. Two comments though: >>> 2. I haven't done

On Wed, 18 May 2005, Chris Lattner wrote: > Yup, something like this should work. Two comments though: > 2. I haven't done much testing with the JIT and tail calls. I wouldn't be > suprised if there are minor issues that need to be fixed. I will try > to take a look and see what remains to be done over the next couple of > days. As I expected, there were issues. I

Hi, just a quick question, how do you set options when you are linking with the LLVM libraries? for example, the option: cl::opt<bool> DisablePatternISel("disable-pattern-isel", cl::Hidden, cl::desc("Disable the pattern isel XXX FIXME"), cl::init(true)); How do I change it from within our

For marking a call site as a tail call you have to call void setTailCall(bool isTC = true) on the CallInst. The calling convention of the function needs to be CallingConv::Fast (currently only fastcc calls are optimized) and the call has to be in tail position of course. To enable tail call optimization in an embedded vm i guess you would include llvm/Target/TargetOptions.h and set the static

On Thu, Sep 11, 2008 at 4:31 PM, Arnold Schwaighofer <arnold.schwaighofer at gmail.com> wrote: > Tail calls through function pointers should work.If not please send a testcase. > > I just added the two examples from the bug (1392) that calls for true > tail call support. They work on my machine (-tailcallopt needs to be > enabled) ;) > > That would be commit 56127. >

Hello, I didn't get any reply to my previous mail about adding floating point intrinsics to the X86 pattern instruction selector... And I could really need some help. Anyway, I think my confusion was caused partly by an already existing bug in the instruction selection for floating point compares. The case which emits code for the special case of comparing against constant 0.0 does not

Tail calls through function pointers should work.If not please send a testcase. I just added the two examples from the bug (1392) that calls for true tail call support. They work on my machine (-tailcallopt needs to be enabled) ;) That would be commit 56127. regards On Thu, Sep 11, 2008 at 11:21 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Arnold implemented tail call. We

On May 16, Chris Lattner wrote: > On Mon, 16 May 2005, Alexander Friedman wrote: > > Would it be possible (ie, relatively straitforward) to do the > > following: Take the code in module A, compile it with the JIT (since > > we cannot make libraries in Windows), and save the resulting binary > > goo in some file. Later (in a different instance of the runtime), with >

Chris Lattner wrote: > On Fri, 11 Mar 2005, Morten Ofstad wrote: >> I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added >> work with the X86ISelPattern, but I'm having some difficulties >> understanding what needs to be done. > > Cool. Here are a couple of requests: > > 1. I don't think we need an "llvm.abs" intrinsic

On 5 Oct 2007, at 20:00, Dale Johannesen wrote: >>> 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 no problem to make the behaviour dependent on the -tail- >>> call-opt flag. i am not sure

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

On Wed, 16 Mar 2005, Morten Ofstad wrote: > Hello, > > I didn't get any reply to my previous mail about adding floating point > intrinsics to the X86 pattern instruction selector... And I could really need > some help. Sorry about that, it slipped through the cracks. :( > Anyway, I think my confusion was caused partly by an already > existing bug in the instruction

On Fri, 11 Mar 2005, Morten Ofstad wrote: > Hello, > > I am trying to make the FP intrinsics (abs, sin, cos, sqrt) I've added work > with the X86ISelPattern, but I'm having some difficulties understanding what > needs to be done. Cool. Here are a couple of requests: 1. I don't think we need an "llvm.abs" intrinsic at the llvm level. This can 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 Andrew, On 04/19/10 14:27, Andrew Friedley wrote: > Sorry for responding to my own message but I would really appreciate > some help with this. > > Looking through the documentation again this morning I noticed that > setSchedulingPreference is a protected method of LLVMTargetLowering, so > it looks like it's not something I can call directly anyway. > Furthermore

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

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 at