similar to: C returning struct by value

On 27 March 2016 at 21:48, Michael Nicolella via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Can someone help me understand why this detail needs to be understood by the frontend, Many of the backends can do automatic demotion to sret, but the front-end still needs to be aware of the issues (particularly around unions, since whether demotion is necessary can depend on more than just

Thanks for the explanation. It's good to hear the situation isn't felt to be ideal. The details here are going to be sensitive to the OS + target that I'm compiling for, right? So the effort here will be to understand and get right the calling convention details for each supported target, yes? Is there any current plan to change the way this works, or is it more of a dreamy cleanup

On Mon, Mar 28, 2016 at 5:14 PM, Michael Nicolella via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for the explanation. It's good to hear the situation isn't felt to > be ideal. > > The details here are going to be sensitive to the OS + target that I'm > compiling for, right? So the effort here will be to understand and get > right the calling

On Tue, Mar 29, 2016 at 9:17 AM, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Mon, Mar 28, 2016 at 5:14 PM, Michael Nicolella via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Thanks for the explanation. It's good to hear the situation isn't felt to >> be ideal. >> >> The details here are going to be sensitive

On Tue, Sep 15, 2009 at 11:55 AM, Dan Gohman <gohman at apple.com> wrote: > > On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: > >> In the latest snapshot from SVN on X86, llc refuses to compile >> functions returning structs larger than two i32 members. >> >> According to the docs, such limitations can be expected to exist on >> other platforms.

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. Any objections?

Kenneth Uildriks wrote: > On Tue, Sep 15, 2009 at 11:55 AM, Dan Gohman <gohman at apple.com> wrote: > >> On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: >> >> >>> In the latest snapshot from SVN on X86, llc refuses to compile >>> functions returning structs larger than two i32 members. >>> >>> According to the docs,

On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: > In the latest snapshot from SVN on X86, llc refuses to compile > functions returning structs larger than two i32 members. > > According to the docs, such limitations can be expected to exist on > other platforms. > > This leads to a number of questions and observations: > > 1. Is there a good way to retrieve the

In the latest snapshot from SVN on X86, llc refuses to compile functions returning structs larger than two i32 members. According to the docs, such limitations can be expected to exist on other platforms. This leads to a number of questions and observations: 1. Is there a good way to retrieve the current target limitations on struct return sizes? 2. The sretpromotion pass does not take struct

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,

Hi, all When I compile the C code containing the next statement to LLVM, *struct A const o = func(...);* I got the next corresponding LLVM bytecode *call void @func(%struct.A* noalias sret %o, ...)* Could you tell me why function "func" with a return value is changed to be one with a void return value and another more parameter %o. Does "noalias sret" play a special role?

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,

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, After removing support for the i64 type in the *CallingConv.td, sret-demotion is performed and we now have a store<(store 8, align 1)> DAG node being generated. Please refer to the attached dag_funcret.pdf DAG visualization. My understanding is that, the second operand(CopyFromReg->Register %1, Register %0 back-up) in the store node is the memory location allocated for the i64 type

Hi llvm-dev, >> The CopyFromReg->CopyToReg->CopyFromReg sequence doesn’t have the chains set correctly: the second CopyFromReg’s input chain isn’t connected to the CopyToReg’s output chain. (This appears to be the same problem in both graphs.) The DAG mentioned was generated by the SelectionDAGBuilder and as much as possible, we only modify the files within our target so I tried

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 All, In the target we are implementing, function return for i64 and f64 types has a different processing. For types i8 to i32, and f32, the return values are stored in their designated return registers (like how other targets does it). For i64 and f64 types, in the function call, after pushing the function parameters into the stack, the address of the allocated return memory space is

Hi all, I'm new on the list, so I want to say hello for everybody! I'm from Hungary and writing a LLVM backend for Tile64 processor as my master's thesis. It's a big time pressure on me, so the thesis will probably describe a backend only providing an assembly printer, but the development is likely to be continued beyond the thesis. For now, I've run into a very annoying

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering