[cfe-commits] r154046 - in /cfe/trunk: include/clang/Driver/Options.td lib/Basic/Targets.cpp lib/Driver/Tools.cpp test/Driver/arm-mfpmath.c

[Sandeep Patel]

On Fri, Apr 6, 2012 at 11:27 PM, Chad Rosier <mcrosier at apple.com> wrote:
>
> On Apr 6, 2012, at 3:53 PM, Sandeep Patel wrote:
>
>> On Fri, Apr 6, 2012 at 10:16 PM, Chad Rosier <michael_rosier at apple.com> wrote:
>>>
>>> On Apr 6, 2012, at 3:13 PM, Sandeep Patel wrote:
>>>
>>>> Is this really necessary as a driver-level option?
>>>>
>>>> Can't this be inferred from other existing tuning choice (e.g. which
>>>> core IP is used)?
>>>
>>> No, that's why it was added.
>>
>> If we have a Cortex-A8 vs A9, we can know which approach is going to
>> be faster always, don't we?
>
> In general, this is the case, but in this instance it's a correctness issue.  The specific code requires the VFP floating point rounding modes to function correctly.

If +neonfp isn't checking for -ffast-math to be set, then that would
seem to be incorrect. Rounding-mode sensitive code should not have
-ffast-math set and that should ensure that that one internal group
gets the results they need.

...
>> I'm generally against providing tweakable driver-level params to
>> people that won't understand them and will constantly fiddle with
>> them, hoping to get better performance. Can't we keep this as a cc1
>> flag only?
>
> gcc has a flag by the same name used for the x86 architecture (not that I'm championing gcc).

That's a very helpful data point. We already have too many flags to
control float ABI, etc., so I wanted to avoid adding any more if we
can.

deep