[LLVMdev] Using CallingConvLower in ARM target

[Sandeep Patel]

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>