search for: argflagsti

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

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

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,

Suppose this structure is passed by value to a function foo(struct S1), struct S1 { int i0; float f0; double d0; long long l0; }; and the ABI dictates the elements of the structure are copied to both integer and floating pointer argument registers in the following way: (i0, f0) => 1st 64-bit integer argument register d0 => 2nd double float argument register (doubles are passed in

On Thu, Oct 20, 2011 at 2:21 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Suppose this structure is passed by value to a function foo(struct S1), > > struct S1 { >  int i0; >  float f0; >  double d0; >  long long l0; > }; > > and the ABI dictates the elements of the structure are copied to both > integer and floating pointer argument registers in the

Although it's not generally needed for ARM's use of CCCustom, I return two bools to handle the four possible outcomes to keep the mechanism flexible: * if CCCustomFn handled the arg or not * if CCCustomFn wants to end processing of the arg or not I placed the "unsigned i" outside those loops because i is used after the loop. If there's a better index search pattern, I'd

On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote: > Although it's not generally needed for ARM's use of CCCustom, I return > two bools to handle the four possible outcomes to keep the mechanism > flexible: > > * if CCCustomFn handled the arg or not > * if CCCustomFn wants to end processing of the arg or not +/// CCCustomFn - This function assigns a location for Val,

On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote: > >> Although it's not generally needed for ARM's use of CCCustom, I return >> two bools to handle the four possible outcomes to keep the mechanism >> flexible: >> >> * if CCCustomFn handled the arg or not >>

I find the lldb cannot display structure type information, such as "print ArgLocs.size()" as follows, -> 593 CCValAssign &VA = ArgLocs[i]; 594 EVT ValVT = VA.getValVT(); 595 ISD::ArgFlagsTy Flags = Ins[i].Flags; 596 bool IsRegLoc = VA.isRegLoc(); (lldb) print ArgLocs.size() error: call to a function

Hi LLVM developers, Don't be quiet :) we need your suggestions for supporting custom CCState, CCAssignFn in D41700. And also RegisterBank in D41653. because it needs to consider about how to support variable-sized register classes concept implemented in D24631. And I think you might have same question when porting to GlobalISel for your Targets, so please give us some directions, thanks

I think I've got all the cases handled now, implementing with CCCustom<"foo"> callbacks into C++. This also fixes a crash when returning i128. I've also included a small asm constraint fix that was needed to build newlib. deep On Mon, Jan 19, 2009 at 10:18 AM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jan 16, 2009, at 5:26 PM, Sandeep Patel wrote:

ARMTargetLowering doesn't need case #1, but it seemed like you and Dan wanted a more generic way to inject C++ code into the process so I tried to make the mechanism a bit more general. deep On Fri, Feb 13, 2009 at 2:34 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 13, 2009, at 2:20 PM, Sandeep Patel wrote: > >> On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng

On Feb 13, 2009, at 2:20 PM, Sandeep Patel wrote: > On Fri, Feb 13, 2009 at 12:33 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> >> On Feb 12, 2009, at 6:21 PM, Sandeep Patel wrote: >> >>> Although it's not generally needed for ARM's use of CCCustom, I >>> return >>> two bools to handle the four possible outcomes to keep

Thanks Sandeep. I did a quick scan, this looks really good. But I do have a question: +/// CCCustomFn - This function assigns a location for Val, possibly updating +/// all args to reflect changes and indicates if it handled it. It must set +/// isCustom if it handles the arg and returns true. +typedef bool CCCustomFn(unsigned &ValNo, MVT &ValVT, + MVT

Sure. Updated patches attached. deep On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote: > >> ARMTargetLowering doesn't need case #1, but it seemed like you and Dan >> wanted a more generic way to inject C++ code into the process so I >> tried to make the mechanism a bit more

On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote: > ARMTargetLowering doesn't need case #1, but it seemed like you and Dan > wanted a more generic way to inject C++ code into the process so I > tried to make the mechanism a bit more general. Ok. Since ARM doesn't need it and it's the only client, I'd much rather have CCCustomFn just return a single bool indicating

On Sat, Jan 3, 2009 at 11:46 AM, Dan Gohman <gohman at apple.com> wrote: > > One problem with this approach is that since i64 isn't legal, the > bitcast would require custom C++ code in the ARM target to > handle properly. It might make sense to introduce something > like > > CCIfType<[f64], CCCustom> > > where CCCustom is a new entity that tells the

Thanks. More questions :-) /// Information about how the value is assigned. - LocInfo HTP : 7; + LocInfo HTP : 6; Do you know why this change is needed? Are we running out of bits? - NeededStackSize = 4; - break; - case MVT::i64: - case MVT::f64: - if (firstGPR < 3) - NeededGPRs = 2; - else if (firstGPR == 3) { - NeededGPRs = 1; - NeededStackSize = 4; -

Sorry left a small bit of cruft in ARMCallingConv.td. A corrected patch it attached. deep On Fri, Feb 13, 2009 at 6:41 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > Sure. Updated patches attached. > > deep > > On Fri, Feb 13, 2009 at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> >> On Feb 13, 2009, at 4:25 PM, Sandeep Patel wrote: