similar to: [LLVMdev] Any reason why fastcc on x86 shouldn't use ECX as a return register?

On Tue, Jan 5, 2010 at 1:22 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Kenneth, > >> Now that we can safely return arbitrarily large structs on x86, it >> seems to me that fastcc, which doesn't have to conform to any >> preexisting ABI, should use ECX as well as EAX and EDX for returning >> {i32,i32,i32} rather than use sret-demotion. > > the

Hi Kenneth, > Now that we can safely return arbitrarily large structs on x86, it > seems to me that fastcc, which doesn't have to conform to any > preexisting ABI, should use ECX as well as EAX and EDX for returning > {i32,i32,i32} rather than use sret-demotion. the x86 trampoline lowering code would need tweaking to check that the ECX register was available for it. Ciao,

Hi, It looks like PDT.getRootNode() returns NULL for: define fastcc void @c974001__lengthy_calculation. 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { entry: br label %bb bb: br label %bb } Isn't it a bug in PostDominatorTree? Please note that this crashes: opt -postdomtree -debug dom_crash.bc I think this should be reported as a bug, -Jakub On Sep 3, 2009, at

Hi Jakub, interesting patch. I ran it over the Ada testsuite and this picked up some problems even without enabling dse-ssu. For example, "opt -inline -dse -domtree" crashes on the attached testcase. Ciao, Duncan. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dom_crash.ll URL:

Hello, This patch adds non-local DSE optimization. It uses Static Single Use representation. This is my first "big" patch, please be tolerant :-) Please note that optimization is disabled by default. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: dse_ssu.patch Type: application/octet-stream Size: 17352 bytes Desc: not available URL:

Jakub Staszak wrote: > Hi, > > It looks like PDT.getRootNode() returns NULL for: > > define fastcc void @c974001__lengthy_calculation. > 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { > entry: > br label %bb > > bb: > br label %bb > } > > > Isn't it a bug in PostDominatorTree? > > Please note that this crashes: >

Hello, Bug is already fixed by Chris (see: http://llvm.org/bugs/show_bug.cgi?id=4915) . I added getRootNode() == NULL condition to my patch. It's not a great solution, but it is enough for now I think. New patch attached. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: dse_ssu-2.patch Type: application/octet-stream Size: 17762 bytes Desc: not

Hi, it seems like SelectionDAGBuilder expects returning of vectors (structures/arrays) to be lowered in either of the two ways: 1. Flatten the complex data types to simple data types, and return them using registers (done by TargetLowering::LowerCallTo) 2. sret demotion: return the address of the complex data type via a stack pointer Is there an option to do sret demotion via a register? if yes,

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

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

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

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

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's requirement. Also care must be taken to make sure the stack stays

On 9/4/2012 11:16 AM, Khaled Mohammed wrote: > > Is there an option to do sret demotion via a register? if yes, do we > have a Target to see an example implementation? Hi Khaled, Check out X86TargetLowering::LowerReturn, and the call to getSRetReturnReg. The SRetReturnReg looks like a hack (each target that uses it, declares this variable individually), but that seems to be the

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 frontend code is a pretty simple for loop, that counts from i = 0; i != 10; i += 1 It gets optimized into and endless loop. export fn entry() void { var array: [10]Bar = undefined; var x = for (array) |elem, i| { if (i == 1) break elem; } else bar2(); } Here's the generated IR: ; ModuleID = 'test' source_filename = "test" target datalayout =

Okay so i implemented an(other :) initial version for X86-32 backend, this time based on TOT: It is not very generic at the moment. Only functions with callingconv::fastcc and the tail call attribute will be optimized. Maybe the next step should be to integrate the code into the other calling convention lowering. Here is what i have at the moment: If callingconv::fastcc is used the

Hello, Arnold. Only quick comments, I'll try to make a full review a little bit later. > 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 >

On Mon, Feb 23, 2009 at 2:13 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > Moreover, I now have evidence that LLVM is not behaving as you expect: > > 3. Adjusting the return value from this function into sret form results in > tail call elimination being performed correctly. Note that this is still > passing a first-class struct by value as an argument to a function

I'm new to using LLVM and I've started work on a compiler for a language that can interface with C. One thing that caught me off guard was returning a struct from a function by value. It seems that when calling a C function I need to emit llvm ir that, in the caller, emits an alloca for the returned structure, and the C function signature should return void and take a first argument with