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: > >> 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 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 and a way to >> author an arbitrary CCAction by including the source directly in the >> TableGen mini-language. This latter change might want a generic change >> to the TableGen language. For example, the syntax might be like: >> >> class foo : CCCustomAction { >> code <<< EOF >> ....multi-line C++ code goes here that allocates regs & mem and >> sets CCValAssign::isCustom.... >> EOF >> } >> >> Does this seem reasonable? An alternative is for 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: > > 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 cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- A non-text attachment was scrubbed... Name: arm_callingconv.diff Type: application/octet-stream Size: 54282 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090206/bfe5289b/attachment.obj>
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, CCValAssign::LocInfo &LocInfo, + ISD::ArgFlagsTy &ArgFlags, CCState &State, + bool &result); Is it necessary to return two bools (the second is returned by reference in 'result')? I am confused about the semantics of 'result'. Also, a nitpick: + unsigned i; + for (i = 0; i < 4; ++i) The convention we use is: + for (unsigned i = 0; i < 4; ++i) Thanks, Evan On Feb 6, 2009, at 6:02 PM, Sandeep Patel wrote:> 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: >> >>> 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 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 and a way to >>> author an arbitrary CCAction by including the source directly in the >>> TableGen mini-language. This latter change might want a generic >>> change >>> to the TableGen language. For example, the syntax might be like: >>> >>> class foo : CCCustomAction { >>> code <<< EOF >>> ....multi-line C++ code goes here that allocates regs & mem and >>> sets CCValAssign::isCustom.... >>> EOF >>> } >>> >>> Does this seem reasonable? An alternative is for 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: >> >> 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 cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > <arm_callingconv.diff>_______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 has DebugLoc changes. I also split out the ARMAsmPrinter fix into it's own patch. deep On Mon, Feb 9, 2009 at 8:54 AM, Evan Cheng <echeng at apple.com> wrote:> 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, CCValAssign::LocInfo &LocInfo, > + ISD::ArgFlagsTy &ArgFlags, CCState &State, > + bool &result); > > Is it necessary to return two bools (the second is returned by > reference in 'result')? I am confused about the semantics of 'result'. > > Also, a nitpick: > > + unsigned i; > + for (i = 0; i < 4; ++i) > > The convention we use is: > > + for (unsigned i = 0; i < 4; ++i) > > Thanks, > > Evan > > On Feb 6, 2009, at 6:02 PM, Sandeep Patel wrote: > >> 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: >>> >>>> 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 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 and a way to >>>> author an arbitrary CCAction by including the source directly in the >>>> TableGen mini-language. This latter change might want a generic >>>> change >>>> to the TableGen language. For example, the syntax might be like: >>>> >>>> class foo : CCCustomAction { >>>> code <<< EOF >>>> ....multi-line C++ code goes here that allocates regs & mem and >>>> sets CCValAssign::isCustom.... >>>> EOF >>>> } >>>> >>>> Does this seem reasonable? An alternative is for 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: >>> >>> 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 cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> <arm_callingconv.diff>_______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- A non-text attachment was scrubbed... Name: arm_callingconv.diff Type: application/octet-stream Size: 55367 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090212/31616686/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: arm_fixes.diff Type: application/octet-stream Size: 590 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090212/31616686/attachment-0001.obj>