[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

[Chris Lattner]

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?

-Chris