search for: cccustom

..., 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 calling convention > code to to let the target do something not easily representable > in the tablegen minilanguage. I am thinking that this requires two changes: add a flag to CCValAssign (take a bit from HTP) to indicate isCustom...

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

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

...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 calling convention >> code to to let the target do something not easily representable >> in the tablegen minilanguage. > > I am thinking that this requires two changes: add a flag to > CCValAssign (take a bit f...

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

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, possibly updating +/// al...

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 >> * if CCCustomFn wants to end processing of the arg or not > > +/// CCCustomFn - This function assigns a location for Val...

...used elsewhere. Can anyone suggest a better way to express > this lowering? 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 calling convention code to to let the target do something not easily representable in the tablegen minilanguage. Dan

...0 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 the mechanism >>>> flexible: >>>> >>>> * if CCCustomFn handled the arg or not >>>> * if CCCustomFn wants to end processing of the arg or not >>&gt...

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 the mechanism >>> flexible: >>> >>> * if CCCustomFn handled the arg or not >>> * if CCCustomFn wants to end processing of the arg or not >> >> +/// CCCustomFn...

...ering 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 whether it > can handle the arg. Would that be ok? > > Thanks, > > Evan > >> >> >> deep >> >> On Fri, Feb 13, 2009 at 2:34 PM, Evan Cheng <evan.cheng at apple.com> >> 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 whether it can handle the arg. Would that be ok? Thanks, Evan > > > 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: >&...

Attached is a prototype patch that uses CCState to lower RET nodes in the ARM target. Lowering CALL nodes will come later. This patch does not handle f64 and i64 types. For these types, it would be ideal to request the conversions below: def RetCC_ARM_APCS : CallingConv<[ CCIfType<[f32], CCBitConvertToType<i32>>, CCIfType<[f64], CCBitConvertToType<i64>>,

...t;>>> 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 >>> whether it >>> can handle the arg. Would that be ok? >>> >>> Thanks, >>> >>> Evan >>> >>>> >>>> >>>> deep >>>> >>>> On Fri, Feb 13,...

...ed 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 whether it >> can handle the arg. Would that be ok? >> >> Thanks, >> >> Evan >> >>> >>> >>> deep >>> >>> On Fri, Feb 13, 2009 at 2:34 PM, Evan Cheng <evan.cheng at apple.com&gt...

...MVT::i32, LocInfo)); > + return true; // we handled it > > Your change isn't handling the "NeededStackSize = 8" case. I believe it is. I've attached two additional test cases. The difference is that this case isn't handled by the CCCustomFns. They fail to allocate any regs and then handling falls through to an CCAssignToStack in ARMCallingConv.td. This is how other targets handle similar allocations. > ++ static const unsigned HiRegList[] = { ARM::R0, ARM::R2 }; > + static const unsigned LoRegList[] = { ARM::R1, ARM::R3 };...

...MVT::i32, LocInfo)); >> + return true; // we handled it >> >> Your change isn't handling the "NeededStackSize = 8" case. > > I believe it is. I've attached two additional test cases. The > difference is that this case isn't handled by the CCCustomFns. They > fail to allocate any regs and then handling falls through to an > CCAssignToStack in ARMCallingConv.td. This is how other targets handle > similar allocations. > >> ++ static const unsigned HiRegList[] = { ARM::R0, ARM::R2 }; >> + static const unsigned LoRegList...

...o)); >>> + return true; // we handled it >>> >>> Your change isn't handling the "NeededStackSize = 8" case. >> >> I believe it is. I've attached two additional test cases. The >> difference is that this case isn't handled by the CCCustomFns. They >> fail to allocate any regs and then handling falls through to an >> CCAssignToStack in ARMCallingConv.td. This is how other targets >> handle >> similar allocations. >> >>> ++ static const unsigned HiRegList[] = { ARM::R0, ARM::R2 }; >>>...

...   return true;  // we handled it >>>> >>>> Your change isn't handling the "NeededStackSize = 8" case. >>> >>> I believe it is. I've attached two additional test cases. The >>> difference is that this case isn't handled by the CCCustomFns. They >>> fail to allocate any regs and then handling falls through to an >>> CCAssignToStack in ARMCallingConv.td. This is how other targets >>> handle >>> similar allocations. >>> >>>> ++  static const unsigned HiRegList[] = { ARM::R0, A...

...t;>>>> >>>>>> Your change isn't handling the "NeededStackSize = 8" case. >>>>> >>>>> I believe it is. I've attached two additional test cases. The >>>>> difference is that this case isn't handled by the CCCustomFns. >>>>> They >>>>> fail to allocate any regs and then handling falls through to an >>>>> CCAssignToStack in ARMCallingConv.td. This is how other targets >>>>> handle >>>>> similar allocations. >>>>> >&g...