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>>, CCIfType<[i64], CCExtractElements<2, i32>>, CCIfType<[i32], CCAssignToReg<[R0, R1]>> ]>; The problem is that i64 handling requires splitting into 2 x i32 registers. I am not sure how to build CCExtractElements as shown. The current organization of CCState::AnalyzeReturn does not allow for reissuing of the RET with an altered set of operands which is the solution used elsewhere. Can anyone suggest a better way to express this lowering? Deep On Fri, Dec 19, 2008 at 6:43 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote:> On Fri, Dec 19, 2008 at 4:54 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> >> On Dec 18, 2008, at 7:05 PM, Sandeep Patel wrote: >> >>> Since there have been no answers, I will have to start at the >>> beginning. >>> >>> One of the first changes I'd like to try is adding the additional >>> registers and the AAPCS VFP variant calling conventions. Is there a >>> reason why the ARM Target isn't using the CCState machinery? >> >> Please clarify. I am not sure what you mean by CCState machinery. > > The ARM Target doesn't use the class CCState. For example, > CCState.AnalyzeCallOperands, CCState.AnalyzeCallReturn, > CCState.AnalyzeReturn, etc. There is no ARMCallingConv.td as there is > for other targets. All calling convention decisions are made manually. > > If there is no reason not to, it might simplify adding the AAPCS > Standard Variants like AAPCS-AFP, etc. since they'll be defined with > TableGen and therefore more readily extended. > >> Evan >> >>> >>> >>> Deep >>> >>> On Fri, Dec 5, 2008 at 5:22 PM, Sandeep Patel >>> <deeppatel1987 at gmail.com> wrote: >>>> >>>> Is anybody actively working on additional ARM target support? >>>> >>>> I need Cortex support (ARMv7, VFPv3, and Neon). >>>> >>>> Thank you. >>> _______________________________________________ >>> 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_ccstate.diff Type: application/octet-stream Size: 10193 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081227/abe6fc79/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: ARMCallingConv.td Type: application/octet-stream Size: 1846 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081227/abe6fc79/attachment-0001.obj>
On Dec 27, 2008, at 4:30 AM, 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:i64 isn't Legal on ARM, so it should already be handled.> > > def RetCC_ARM_APCS : CallingConv<[ > CCIfType<[f32], CCBitConvertToType<i32>>, > CCIfType<[f64], CCBitConvertToType<i64>>, > CCIfType<[i64], CCExtractElements<2, i32>>, > > CCIfType<[i32], CCAssignToReg<[R0, R1]>> > ]>; > > The problem is that i64 handling requires splitting into 2 x i32 > registers. I am not sure how to build CCExtractElements as shown. The > current organization of CCState::AnalyzeReturn does not allow for > reissuing of the RET with an altered set of operands which is the > solution 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
Hi Sandeep,
Dan's idea of adding CC custom lowering support is sound. Can you add
that support?
Your patch looks good. I look forward to a more complete patch. But I
do have a nitpick:
Index: include/llvm/CodeGen/CallingConvLower.h
==================================================================---
include/llvm/CodeGen/CallingConvLower.h (revision 60966)
+++ include/llvm/CodeGen/CallingConvLower.h (working copy)
@@ -32,7 +32,8 @@
Full, // The value fills the full location.
SExt, // The value is sign extended in the location.
ZExt, // The value is zero extended in the location.
- AExt // The value is extended with undefined upper bits.
+ AExt, // The value is extended with undefined upper bits.
+ BCnv // The value is bitconverted in the location
// TODO: a subset of the value is in the location.
};
How about BCvt instead of BCnv? Also, please substitue bit-convert for
bitconvert in comments.
Thanks,
Evan
On Jan 3, 2009, at 11:46 AM, Dan Gohman wrote:
>
> On Dec 27, 2008, at 4:30 AM, 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:
>
> i64 isn't Legal on ARM, so it should already be handled.
>
>>
>>
>> def RetCC_ARM_APCS : CallingConv<[
>> CCIfType<[f32], CCBitConvertToType<i32>>,
>> CCIfType<[f64], CCBitConvertToType<i64>>,
>> CCIfType<[i64], CCExtractElements<2, i32>>,
>>
>> CCIfType<[i32], CCAssignToReg<[R0, R1]>>
>> ]>;
>>
>> The problem is that i64 handling requires splitting into 2 x i32
>> registers. I am not sure how to build CCExtractElements as shown. The
>> current organization of CCState::AnalyzeReturn does not allow for
>> reissuing of the RET with an altered set of operands which is the
>> solution 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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);