similar to: [LLVMdev] Calling-convention lowering proposal

Dan Gohman wrote: > Hello, > > Attached is a patch which significantly reworks how calls, incoming > arguments, and outgoing return values are lowered. It's a major change, > affecting all targets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary differences between targets,

On Apr 23, 2009, at 8:09 PM, Dan Gohman wrote: > Attached is a patch which significantly reworks how calls, incoming > arguments, and outgoing return values are lowered. It's a major > change, > affecting all targets, so I'm looking for feedback on the approach. > > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary

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

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

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,

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

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

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

On 3 December 2012 10:42, Mayur Pandey <mayurthebond at gmail.com> wrote: > So this seems to be the cause of the problem. I guess you're mixing two different problems. First, is the possible lack of conformance with the ABI you state, which I can't comment since I don't know that ABI very well. Second, is the fact that clang is not printing correct debug information (or is

+ Eli Friedman as he often has very insightful comments regarding back end changes. On Fri, Jan 4, 2019 at 9:03 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > The changes seem fine to me. I don't think this is excessively intrusive > and it accomplishes what is needed by targets whose call lowering can > introduce illegal types. > Adding Justin Bogner as 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

Good to know, thanks! Currently I'm just not declaring an i8 register class since we only have load/store/convert available for that type. This works fine for most uses, but becomes a hassle when dealing with function parameters. For example, if the function argument is i8, the code in LowerFormalArguments sees it as an i16 since that is the next target legal type. For my target, we need

Hi, Dan > The goal of the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary differences between targets, and to > facilitate future refactoring and feature work. I quickly looked over the patch and it seems to be a significant cleanup of all really ugly lowering code! Maybe it will be possible to provide some dummy implementation of LowerFormalArguments /

On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <tom at stellard.net> wrote: > On Thu, Aug 08, 2013 at 01:51:53PM -0400, Justin Holewinski wrote: > > Good to know, thanks! > > > > Currently I'm just not declaring an i8 register class since we only have > > load/store/convert available for that type. This works fine for most > uses, > > but becomes a

Hello, LLVM devs. I'm compiling the following simple IR: define dso_local i32 @main(i32 %argc, i8** %argv) { entry: %retval = alloca i32, align 4 %argc.addr = alloca i32, align 4 %argv.addr = alloca i8**, align 8 store i32 0, i32* %retval, align 4 store i32 %argc, i32* %argc.addr, align 4 store i8** %argv, i8*** %argv.addr, align 8 ret i32 0 } using `llc -march=sparc

On Thu, Aug 08, 2013 at 01:51:53PM -0400, Justin Holewinski wrote: > Good to know, thanks! > > Currently I'm just not declaring an i8 register class since we only have > load/store/convert available for that type. This works fine for most uses, > but becomes a hassle when dealing with function parameters. For example, > if the function argument is i8, the code in

It's been on the back-burner for awhile. I'll clean it up and post it for review soon. On Tue, Aug 27, 2013 at 7:48 PM, Tom Stellard <tom at stellard.net> wrote: > On Thu, Aug 08, 2013 at 04:25:25PM -0400, Justin Holewinski wrote: > > On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <tom at stellard.net> wrote: > > > > > On Thu, Aug 08, 2013 at

On Thu, Aug 08, 2013 at 04:25:25PM -0400, Justin Holewinski wrote: > On Thu, Aug 8, 2013 at 3:59 PM, Tom Stellard <tom at stellard.net> wrote: > > > On Thu, Aug 08, 2013 at 01:51:53PM -0400, Justin Holewinski wrote: > > > Good to know, thanks! > > > > > > Currently I'm just not declaring an i8 register class since we only have > > >

Is there a way to define a register class that is storage-only? I want to have an i8 register class that I can use for loads/stores/converts, but that does not support arithmetic. It seems addOperationAction(ISD::ADD, MVT::i8, Promote) and SetPromotedToType(ISD::ADD, MVT::i8, MVT::i16) are not sufficient, as the legalizer just looks at whether or not the underlying type is legal (which it is).

Hello, I'm part of the (sadly fairly small) community of PS2 hackers. The current cross-toolchain for the PS2 is based on GCC 3.2.3, an outdated and buggy compiler, which I have personally gotten tired of working with, so I would like to port Clang as a newer cross-compiler for the PS2. However, the PS2 has some notable quirks which make this a non-trivial task for the current compiler. It