[LLVMdev] Using CallingConvLower in ARM target

Evan Cheng echeng at apple.com
Mon Feb 9 08:54:53 PST 2009


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




More information about the llvm-dev mailing list