[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 Thu, Jun 11, 2009 at 11:29 AM, Chris Lattner<clattner at apple.com> wrote:
>
> On Jun 8, 2009, at 3:53 PM, Anton Korobeynikov wrote:
>
>> Author: asl
>> Date: Mon Jun  8 17:53:56 2009
>> New Revision: 73095
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=73095&view=rev
>> Log:
>> The attached patches implement most of the ARM AAPCS-VFP hard float
>> ABI. The missing piece is support for putting "homogeneous aggregates"
>> into registers.
>
> Philosophical question here: shouldn't ABI changes like this be part
> of the target triple?  llvm-gcc already munges a "GNU" target triple
> into an llvm target triple.  Wouldn't it be appropriate to do
> something like that for this?  Do we really support multiple different
> (and selectable) ABIs on the same triple?

Yes. At few reasons come to mind:

* Existing code for ARM is generally all soft float and we need to be
able to support that code.
* We're following existing practice for the ARM EABI.
* Units like FPU/NEON are optional when designing an SoC with an ARM.
* The FPU/NEON units aren't necessarily enabled even if present. For
at least kernel development, there is a need to build code that can do
without.

deep