[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 Fri, Jun 12, 2009 at 11:12 AM, Evan Cheng<evan.cheng at apple.com> wrote:
>
> On Jun 11, 2009, at 4:47 PM, Sandeep Patel wrote:
>
>> On Thu, Jun 11, 2009 at 2:33 PM, Bob Wilson<bob.wilson at apple.com>
>> wrote:
>>>
>>> On Jun 11, 2009, at 11:52 AM, Evan Cheng wrote:
>>>>
>>>> On Jun 11, 2009, at 11:32 AM, Chris Lattner wrote:
>>>>>
>>>>> Why not put this into the target triple?  Major ABI issues like
>>>>> this
>>>>> seem like they belong in the triple.
>>>>
>>>> It's not always clear what information we want to encode in triplet.
>>>> In this case, it seems reasonable to encode float abi in the
>>>> triplet.
>>>> But how do we want encode this? Do we want to use it to toggle fp
>>>> abi
>>>> for any target, e.g. arm-apple-darwin-apcs?
>>>
>>> Since target triples are a GNU thing, it would be a good idea to be
>>> compatible with GCC on this.  I know that for the base AAPCS ABI GCC
>>> uses an "eabi" suffix on the OS portion of the triple, e.g., arm-
>>> linux-
>>> gnueabi.
>>>
>>> When I last worked on GCC, it had no support for the "hardfloat"
>>> AAPCS
>>> ABI, but I heard that it was added since then.  Does anyone know if
>>> GCC uses something in the triple ("eabi-hardfloat" suffix??) to
>>> indicate this?
>>>
>>> Since this fp ABI is an extension of AAPCS, it would only make sense
>>> to allow toggling something in the target triple for targets that use
>>> AAPCS (not Darwin).
>>
>> 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 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.

deep