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: typedef bool CCCustomFn(unsigned ValNo, MVT ValVT, MVT LocVT, CCValAssign::LocInfo LocInfo, ISD::ArgFlagsTy ArgFlags, CCState &State, bool &result);
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
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>