[llvm-commits] [llvm] r73095 - in /llvm/trunk: include/llvm/Target/TargetMachine.h include/llvm/Target/TargetOptions.h lib/Target/ARM/ARMCallingConv.td lib/Target/ARM/ARMISelDAGToDAG.cpp lib/Target/ARM/ARMISelLowering.cpp lib/Target/ARM/ARMRegist

[Sandeep Patel]

On Sun, Jun 14, 2009 at 11:07 PM, Chris Lattner<clattner at apple.com> wrote:
>
> On Jun 12, 2009, at 4:52 PM, Sandeep Patel wrote:
>
>> On Fri, Jun 12, 2009 at 4:36 PM, Chris Lattner<clattner at apple.com> wrote:
>>>
>>> On Jun 12, 2009, at 11:12 AM, Evan Cheng wrote:
>>>>>
>>>>> GCC did not change the target triple to indicate use of hard float;
>>>>> it's still arm-linux-gnueabi. GCC even allows a function attribute to
>>>>> change the ABI per function in support of kernel development and
>>>>> other
>>>>> cases where one may need to mix ABIs (e.g. a library that supports
>>>>> legacy soft float applications, etc.).
>>>>
>>>> Ok. Then it makes more sense for it to be a function note. We should
>>>> be able to figure out a way to change calling convention (and other
>>>> subtarget states).
>>>
>>> I agree: if one program can make use of multiple ABIs at the same
>>> time, it should not be in the triple.
>>>
>>>> I previously planned to make this a CC (64, 65, 66,...) on every
>>>> function, but it seemed silly to not have a default be applied to
>>>> handle C, fastcall, etc.
>>>
>>> What do you mean?
>>
>> I originally considered having the front-end tag every function with
>> the exact CC that applied to it. No function would be C or fastcall.
>> They'll all be tagged with a target-unique CC (CallingConv::ARM_APCS =
>> 64, CallingConv::ARM_AAPCS = 65, CallingConv::ARM_AAPCS_VFP = 66,
>> etc.).
>
> Ok, after talking to Anton about this on IRC, how about a third proposal :).
>
> 1. Each different CC gets its own number, e.g. ARM_APCS = 64,
> CallingConv::ARM_AAPCS = 65, CallingConv::ARM_AAPCS_VFP = 66, etc.
> 2. The default mapping of "ccc" depends on the target triple.
>
> This means that llvm-gcc can just produce ccc for most cases (leading to
> clear and simple IR) but that per-function attributes will work correctly.
>  What do you think?

I chatted with Anton on IRC about an hour later. :-)

It sounds like we're talking about a patch I was planning to prepare
anyway, but Anton will get to it first.

deep