search for: tailcaller

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 i32 @tailcaller(i32 %in2, i32 %in1) %ww = sub i32 %q, 6 ret i32 %ww } Built with (ToT LLVM): llc &lt...

...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 i32 @tailcaller(i32 %in2,...

...isting 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 i32 @tailcaller(i32 %in2, i32 %in1) > %ww = sub i32 %q,...

...g it's arguments 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...

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 f1(int (*pf4)(int a, int b, int c, int d)) { return pf4(1, 2, 3, 4); } int f2(vtable_t *vt) { return vt->pf4(1, 2, 3, 4); } gcc and clang will not tailcall these on arm with -O3. int f3(int (*pf5)(int a, int b, int c, int d, int e)) { return pf5(1, 2, 3,

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,

...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 i32 @tailcaller(i32 %in2, i32 %in1) > %ww = sub i32 %q, 6...

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

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

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

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, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really

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

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

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

Happy 2011, everybody! It seems -tailcallopt prevents tailcall optimization when both caller and callee have ccc, even when it is optimized without an option -tailcallopt. Is it intended or misoptimized? In X86ISelLowering.cpp:X86TargetLowering::IsEligibleForTailCallOptimization(): if (GuaranteedTailCallOpt) { if (IsTailCallConvention(CalleeCC) && CCMatch) return true;

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

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