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

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

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

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

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 >

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

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

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. I assume I have to add new nodetypes for the FP instructions to SelectionDAGNodes.h, and make nodes for these in SelectionDAGLowering::visitCall when I find the intrinsic... The part I don't quite

Chris Lattner wrote: > On Wed, 16 Mar 2005, Morten Ofstad wrote: >> The case which emits code for the special case of comparing against >> constant 0.0 does not return after generating it's code, so the normal >> compare is also generated! As far as I can tell it should return right >> after this: >> >> BuildMI(BB, X86::SAHF, 1); >> >>

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

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