search for: cccustomfn

...ng 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, possibly > updating > +/// all args to reflect changes and indicates if it handled it. It > must set > +/// isCustom if it hand...

...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 >>> +/// all args to reflect changes and indicates if it handled it. It &gt...

...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 >> +/// all args to reflect changes and indicates if it handled it. It >> must set >&...

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

...: > 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: >&gt...

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

...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 }; &g...

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

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

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 +/// all args to reflect changes and indicates if it handled it. It must set +/// isCustom if it handles the arg and returns true....

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 be happy to change it. Attached is an updated patch against HEAD that ha...

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

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

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

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

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 &LocVT,...

...s will have to return two >> results: if the CC processing is finished and if it the func succeeded >> or failed: > > I like the second solution better. It seems rather cumbersome to embed > multi-line c++ code in td files. > > Evan >> >> >> typedef bool CCCustomFn(unsigned ValNo, MVT ValVT, >> MVT LocVT, CCValAssign::LocInfo LocInfo, >> ISD::ArgFlagsTy ArgFlags, CCState &State, >> bool &result); >> _______________________________________________ >> LLVM Developers mailing lis...

...r CCCustom to take a string that names a function to be called: CCIfType<[f64], CCCustom<"MyCustomLoweringFunc">> the function signature for such functions will have to return two results: if the CC processing is finished and if it the func succeeded or failed: typedef bool CCCustomFn(unsigned ValNo, MVT ValVT, MVT LocVT, CCValAssign::LocInfo LocInfo, ISD::ArgFlagsTy ArgFlags, CCState &State, bool &result);

...the function signature for such functions will have to return two > results: if the CC processing is finished and if it the func succeeded > or failed: I like the second solution better. It seems rather cumbersome to embed multi-line c++ code in td files. Evan > > > typedef bool CCCustomFn(unsigned ValNo, MVT ValVT, > MVT LocVT, CCValAssign::LocInfo LocInfo, > ISD::ArgFlagsTy ArgFlags, CCState &State, > bool &result); > _______________________________________________ > LLVM Developers mailing list > LLVMdev at...