similar to: arm tailcall with many parameters?

Sorry that also suffered from signature mismatch. So how about more like: typedef struct vtable_t { int (*pf4)(int a, int b, int c, int d); int (*pf5)(int a, int b, int c, int d, int e); } vtable_t; int f3(int (*pf5)(int a, int b, int c, int d, int e), int a, int b, int c, int d) { return pf5(a, b, c, d, d + d); } int f4(vtable_t *vt, int a, int b, int c, int d) { return vt->pf5(a, b,

In order to test the tail call optimization i created quite a few .ll files and added them to the SingleSource directory in the test-suite. For example llvm-test/SingleSource/Tailcall/tailcall1-2.ll. Since i don't want opt to inline the tailcalls away :) i changed the rules in the Makefile situated in the TailCall directory. I want to compare the output of a file compile with normal llc with

On 2009-02-24 12:35, Jon Harrop wrote: > On Tuesday 24 February 2009 00:16:37 Dan Gohman wrote: > >> On Feb 23, 2009, at 5:59 AM, Anton Korobeynikov wrote: >> >>> This is not true in general and highly target- and CC- dependent. For >>> example, you can ran out of registers and then your struct can be >>> passed >>> partly in registers

tailcall optimization stop working in jit (lli) in revision 45527. i guess this is because the jit is tailjmping to the wrong function address. the following change would reenable tailcallopt in jit. But i am pretty sure that this is not the correct fix (since i don't really understand what is going on :). maybe evan can comment on this? regards arnold Index:

Here is a patch to improve argument lowering for tail calls. Before this patch all outgoing arguments were move to the stack slot where they would go on a normal function call and from there moved back to the tail call stack slot to prevent overwriting of values. After this patch only arguments that source from callers arguments (formal_arguments) are lowered this way. I moved some code

Hello Cameron, thanks a lot for your fast answer, which just makes me curious if making ARM tailcalls on par with x86 in the future is on some of the development plans already? If not, then what do you think is the complexity of such work? Thanks! Karel On 06/17/11 10:41 PM, Cameron Zwarich wrote: > They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative

John, I've moved with patches to HEAD and unfortunately the comments about disabling tailcalls do not go away with this update. Please see ARMTargetLowering::LowerCall in lib/Target/ARM/ARMISelLowering.cpp line 1208 and later. It looks like man can use -arm-tail-calls, but one never knows how good it is since the comment tells it clearly: // Temporarily disable tail calls so things

They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative about when to use tail calls, and doesn't support GuaranteedTailCallOpt, which might be necessary for GHC. Cameron On Jun 17, 2011, at 1:31 PM, Karel Gardas wrote: > > John, > > I've moved with patches to HEAD and unfortunately the comments about > disabling tailcalls do not go

I don't know if GuaranteedTailCallOpt is in anyone's plans. It might be a good idea to implement some time. I am not sure what GHC's exact needs are, though. Cameron On Jun 17, 2011, at 1:49 PM, Karel Gardas wrote: > > Hello Cameron, > > thanks a lot for your fast answer, which just makes me curious if making ARM tailcalls on par with x86 in the future is on some of

On Tuesday 24 February 2009 00:16:37 Dan Gohman wrote: > On Feb 23, 2009, at 5:59 AM, Anton Korobeynikov wrote: > > This is not true in general and highly target- and CC- dependent. For > > example, you can ran out of registers and then your struct can be > > passed > > partly in registers and partly on stack. And depending on the stack > > frame size of the callee

Felix, > Great! Are there other issues I should be aware of? There might be some issues wrt tailcalls, but I'd not expect anything else to be major broken. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Jun 16, 2011, at 1:35 PM, Karel Gardas wrote: > I'm working on implementing GHC specific call convention into LLVM 2.9. I've chosen LLVM 2.9 as a kind of stable reference point and I would like to know how mature is ARM code generation chain inside this release. I've had a hope that perhaps Apple as a main sponsor of LLVM is using LLVM for their ARM based iOS software

Hello, I'm working on implementing GHC specific call convention into LLVM 2.9. I've chosen LLVM 2.9 as a kind of stable reference point and I would like to know how mature is ARM code generation chain inside this release. I've had a hope that perhaps Apple as a main sponsor of LLVM is using LLVM for their ARM based iOS software development, but I'm not sure if I'm right

On Nov 29, 2009, at 2:19 AM, Albert Graef wrote: > Have there been any changes to the x86-64 backend of the JIT which might > break tail call elimination? I didn't see any announcements about major > changes in the JIT on the ml, so I have no idea what might be going > wrong there. I haven't tested it, but the following pattern in X86Instr64bit.td looks suspicious as it

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

Hi, Thanks for the tip. I went to the Netherlands last week so didn't get a chance to try this out until this week. I upgraded to samba 2.2.3a and that helped. The bad news is that it only solved some of the problems. The file link to the floppy backs up now as the translation of the link is consistent somehow, but the character translation on the $ (dollar sign) and ? (pound sign) is not

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

Great! Are there other issues I should be aware of? Félix Le 2010-11-25 à 07:43:23, Anton Korobeynikov a écrit : > Hello Felix > >> I have a project in mind that involves using the JIT for a few targets (x86 >> and x86_64 processors on Mac OS, Linux and Windows). However, there is an >> open bug that says LLVM generates incorrect code for Win64. >> Eli's last

Implementing tail call opt could look like the following: 0.)a fast calling convention (maybe use the current CallingConv::Fast, or create a CallingConv::TailCall) 1.) lowering of formal arguments like for example x86_LowerCCCArguments in stdcall mode we need to make sure that later mentioned CALL_CLOBBERED_REG is not used (remove it from available registers in callingconvention for

0, i32 %1) >> >> Note that if you have a series of sequential recursive tail calls this >> move will only performed once (at the bottom of the recursion, >> respectively when the recursion returns) so it's impact on performance >> should be minimal. > > Hmm, that makes it sound as though the moves between a tail call and the > following return are