[llvm-commits] [llvm] r83122 - in /llvm/trunk: include/llvm/Target/TargetSubtarget.h lib/CodeGen/LLVMTargetMachine.cpp lib/CodeGen/PostRASchedulerList.cpp lib/Target/ARM/ARM.td lib/Target/ARM/ARMSubtarget.cpp lib/Target/ARM/ARMSubtarget.h test/Co

[Sandeep Patel]

"neonfp" is an optimization, not an ABI or hardware-enabling feature.
-mattr=+neonfp causes regular FP ops to be handled in the NEON unit
instead of the VFP unit and thus avoid switching penalties. -mfpu=neon
merely enables use of NEON. (e.g. vector ops become legal)

Perhaps there's room for a target-neutral way of enabling
optimizations where FP ops are handled by a vector unit? Similar
choices would apply to AltiVec and SSE, particularly in cases where
the ABI doesn't already force that choice. If not, David's override
flag will work fine.

deep

On Wed, Sep 30, 2009 at 8:52 PM, Jim Grosbach <grosbach at apple.com> wrote:
> Does -mfpu=neon not do the right thing when using llvm-gcc? If not, we
> should fix that.
>
>
> On Sep 30, 2009, at 12:49 PM, Sandeep Patel wrote:
>
>> I'd actually prefer if there were a way to toggle codegen choices like
>> neonfp from the llvm-gcc command line instead of using -mattr. Perhaps
>> the fix here is to add -mattr to llvm-gcc.
>>
>> deep
>>
>> On Wed, Sep 30, 2009 at 4:58 PM, David Goodwin <david_goodwin at apple.com>
>> wrote:
>>>
>>> I suppose I could set the default programmatically based on the CPU
>>> string, and then have a hidden tri-state flag (keep default, force on,
>>> force off) for overriding. Note that we have another attribute like
>>> this that is used to indicate that NEON instructions should be used
>>> for single-precision FP.
>>>
>>> David
>>>
>>> On Sep 30, 2009, at 8:40 AM, David Goodwin wrote:
>>>
>>>> I did add a subtarget hook to control post-ra scheduling. And by
>>>> default it is off except for the one CPU that is ready for it
>>>> (cortex-a8). But there needs to be a way to override the default (in
>>>> either direction), as well as a way to set the default for a
>>>> particular CPU. -mattr satisfies both of those requirements. Can I
>>>> get the same behavior in a different way?
>>>>
>>>> Evan, all CPUs have an itinerary (even if it is an empty itinerary)
>>>> so I don't think that can be used... and we would still need a way
>>>> to override the default.
>>>>
>>>> David
>>>>
>>>> On Sep 30, 2009, at 12:43 AM, Evan Cheng wrote:
>>>>
>>>>>
>>>>> On Sep 29, 2009, at 10:16 PM, Chris Lattner wrote:
>>>>>
>>>>>>
>>>>>> On Sep 29, 2009, at 5:10 PM, David Goodwin wrote:
>>>>>>
>>>>>>> Author: david_goodwin
>>>>>>> Date: Tue Sep 29 19:10:16 2009
>>>>>>> New Revision: 83122
>>>>>>>
>>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=83122&view=rev
>>>>>>> Log:
>>>>>>> Remove -post-RA-schedule flag and add a TargetSubtarget method to
>>>>>>> enable post-register-allocation scheduling. By default it is off.
>>>>>>> For ARM, enable/disable with -mattr=+/-postrasched. Enable by
>>>>>>> default for cortex-a8.
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> -mattr should be used for CPU attributes, not for optimization
>>>>>> flags.
>>>>>> Having a subtarget hook (or even TargetMachine hook) to indicate
>>>>>> whether this should default to on or not makes sense to me, but
>>>>>> should
>>>>>> it really be controlled via -mattr?
>>>>>
>>>>> I think ARM target should run postalloc scheduling when scheduling
>>>>> itinerary is available for the given cpu?
>>>>>
>>>>> Evan
>>>>>
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>> _______________________________________________
>>>>>> llvm-commits mailing list
>>>>>> llvm-commits at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>