search for: tailcal

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

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

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

Hi Arnold, Thanks for the insights. My comments below: On Thu, Feb 14, 2013 at 5:30 PM, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > When you enable -tailcallopt you get support for tail calls between functions with arbitrary stack space requirements. That means the calling convention has to change slightly. E.g the callee is responsible for removing it's arguments of the stack. The caller cannot transitively know the tail callee's tailcallee...

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, 4, 5); } int f4(vtable_t *vt) { return vt->pf5(1, 2, 3, 4, 5); } Could you not allocate an extra word on the stack, in the first position, store the return address there, and pop it to pc (...

...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, c, d, d + d); } - Jay ________________________________ From: Jay K Sent: Wednesday, March 28, 2018 9:29 AM To: llvm-dev at lists.llvm.org Subject: arm tailcall with many parameters? 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...

When you enable -tailcallopt you get support for tail calls between functions with arbitrary stack space requirements. That means the calling convention has to change slightly. E.g the callee is responsible for removing it's arguments of the stack. The caller cannot transitively know the tail callee's tailcallee...

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 a file compiled with llc -tailcallopt. So my SingleSource/TailCall/Makefile look...

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

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

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

...hat source from callers arguments (formal_arguments) are lowered this way. I moved some code that would otherwise be duplicated to a new function 'GetMemCpyWithFlags'. Okay to commit? regards arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: tailcall-improvement.patch Type: application/octet-stream Size: 10604 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080108/6d29e8c3/attachment.obj>

...> it means death)? TOT = Top of Tree. But yes, many abbrevations has very funny meaning in different languages (TOT = "that" in russian :) ) > So what i will be trying then is to emit a copytoreg from the virtual > register holding the > function pointer to ecx before the tailcall node. This seems to be the right way to do the things. > the downside here is that ECX is no longer free for passing function > arguments. (i am using the x86_fastcall semantics at the moment with > first two arguments stored in ecx,edx) This is the most problematic stuff here. Some...

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 away with this update. Please see > ARMTargetLowering::Low...

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 argument passing?) 2.)lowering of the call: *if it can be sh...

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

...structs are >> converted to a set of *virtual* registers holding their first-class fields, >> which may of course be passed on the stack when physical registers run >> short, in exactly the same manner as with lots of scalar arguments. >> > > Exactly. In case of tailcall(+fastcc?), can't this be done in constant stackspace? First time you allocate stackspace to pass the parameters, then all other tailcalls will reuse the stackspace that it got its parameters in, to pass parameters to the next tailcall. Best regards --Edwin

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

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

...o 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 redundant? I am not sure i understand what you mean by redundant. What i was trying to say is that if you have i32 a() { %1 = tailcall b() ret %1 } i32 b() { %1 = tailcall c() ret %1 } i32 c() { %1 = tailcall d() ret %1 } i32 d() { ret i32 5 } only d() will actually perform the return i.e the move of the result to register %eax on x86 or in case of a struct return the move to whatever registers/(stackslots?) are...