similar to: [LLVMdev] [cfe-commits] Fix handling of ARM homogenous aggregates

Hi Tim, > So I've come to the conclusion that the real flaw is LLVM > not exposing enough information to the target-dependent > backend code for it to do the right thing. We also had this problem. You might find this patch useful as a starting point: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048266.html /Patrik Hägglund -----Original Message----- From: llvmdev-bounces

On Wednesday 04 Apr 2012 12:41:49 Patrik Hägglund H wrote: > Hi Tim, > > > So I've come to the conclusion that the real flaw is LLVM > > not exposing enough information to the target-dependent > > backend code for it to do the right thing. > > We also had this problem. You might find this patch useful as a starting > point:

On Wednesday 04 Apr 2012 13:27:07 Tim Northover wrote: > Putting that information in the InputArg/OutputArg and incorporating it the > CCAssignFn interface allows a more straightforward implementation in the > targets, in my view (for both our uses). It's also information that's > readily available when InputArg/OutputArgs are being constructed. In your > case: > >

Hi Tim > I'm not sure I follow this point. Is preserving the source language a bad > thing for some reason I'm missing? Certainly, if it affects optimisation it > would be. Let's consider one example: union { float foo[4]; int bar[3]; }; This is definitely not a HFA. However, such a union can be represented via several different things in LLVM IR: [4 x float], [4 x

> I think that ABI of LLVM IR level is different from ABI on real architecture > such as ARM or x86. ABI of LLVM IR level doesn't consider about register > usage. It just describes parameters and padding information related to > alignment of parameters. I'm not sure what you mean here. LLVM's IR certainly doesn't care about registers and so on, but the LLVM backends

Hi all, I think that ABI of LLVM IR level is different from ABI on real architecture such as ARM or x86. ABI of LLVM IR level doesn't consider about register usage. It just describes parameters and padding information related to alignment of parameters. As Anton mentioned, LLVM have expressed ABI information on bitcode using front-end. If someone wants to maintain information from high level

Tim, > Opinions, anyone? (Hint hint). I think here stuff should be thought of from different points. While providing source type for argument might be beneficial, it might cause moving the code from frontend to backend. Consider e.g. passing struct by value including crazy padding inside. The ABI might specify that padding should be removed and struct is passed field-by-field. Also, note that

Hi Josef, > Okay, I've done a lot more testing and I now have a .bc file that compiles for x86, sparc, mips but refuses to compile for the mblaze and powerPC backends because of the calling convention. Is there anyone that would know how to fix the microblaze calling convention or point me in the right direction on how to fix it? what does "refuses to compile" mean? I.e. what

> what does "refuses to compile" mean? I.e. what error do you get? > Specifically I get this message when compiling with the default -mattr: Call result #2 has unhandled type i32 UNREACHABLE executed at CallingConvLower.cpp:162! 0 llc 0x0000000100a1e115 PrintStackTrace(void*) + 38 1 llc 0x0000000100a1e6d0 SignalHandler(int) + 254 2

Hello, I am working on a backend for a custom ISA that is somewhat similar to the MicroBlaze ISA so I've decided to use that as a starting point. I am trying to compile a custom ray tracer (lots of floating point) and the llvm-g++ frontend generates an fneg instruction which is not supported by the MBlaze backend in the 2.8 release. I added code to emit an fneg assembly instruction and now

LLVM code base seems to be full of base/interface classes, which have methods like virtual SDValue LowerCall(SDValue Chain, SDValue Callee, CallingConv::ID CallConv, bool isVarArg, bool &isTailCall, const SmallVectorImpl<ISD::OutputArg> &Outs, const SmallVectorImpl<SDValue> &OutVals, const

I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. > On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This question came about through reviewing work from Leslie Zhai on GlobalISel > support for RISC-V, which also motivated me to revisit code which I've always > felt was a

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

On 4 January 2018 at 17:10, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. Thanks for the insight Daniel, much appreciated. >> * MipsCCState: adds bool

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, and to facilitate future refactoring and feature work.

This question came about through reviewing work from Leslie Zhai on GlobalISel support for RISC-V, which also motivated me to revisit code which I've always felt was a bit clunky. Calling convention lowering in LLVM is typically handled by functions conforming to the CCAssignFn typedef: typedef bool CCAssignFn(unsigned ValNo, MVT ValVT, MVT LocVT,

> On 4 Jan 2018, at 10:51, Alex Bradbury <asb at lowrisc.org> wrote: > > On 4 January 2018 at 17:10, Daniel Sanders via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I haven't dug into the GlobalISel calling convention code much but I can comment on the

Byval does not work for me, it will try to split the struct to fit into available core registers and the rest on stack. Sent from my iPhone On Oct 23, 2012, at 5:01 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > In llvm-gcc, this decision was handled near llvm-arm.cpp:2737 in llvm_arm_aggregate_partially_passed_in_regs(). Basically, available registers would be counted up and if

At the time, the ARM target didn't actually handle byval. Now it does. You should be able to get the old struct passing capability if you don't apply an attribute at all. Alex On Oct 23, 2012, at 10:00 PM, Manman Ren wrote: > > Byval does not work for me, it will try to split the struct to fit into available core registers and the rest on stack. > > Sent from my iPhone

In llvm-gcc, this decision was handled near llvm-arm.cpp:2737 in llvm_arm_aggregate_partially_passed_in_regs(). Basically, available registers would be counted up and if the HA didn't fit, it went byval instead. I agree that we should unify this sort of logic in one place. I'm not sure that onstack is the best interim step toward that. Does byval work here? Alex On Oct 23, 2012, at