[llvm-commits] [PATCH] Aggressive FMA formation mode.

Stephen Canon scanon at apple.com
Tue Jun 19 13:36:19 PDT 2012


On Jun 19, 2012, at 4:03 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> On Tue, 19 Jun 2012 18:56:13 +0000
> Sandeep Patel <deeppatel1987 at gmail.com> wrote:
> 
>> On Tue, Jun 19, 2012 at 4:58 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>>> On Mon, 18 Jun 2012 20:41:56 -0700
>>> Lang Hames <lhames at gmail.com> wrote:
>>> 
>>>> Hal - I've updated the guards on FMA formation for PPC, but by
>>>> default FMAs will no longer be formed. If this is a problem, would
>>>> it be possible to have your FMA-formation guard rely on a PPC
>>>> specific "disable-FMA" option? I'd like to keep
>>>> AllowExcessFPPrecision as the guard for target independent FMA
>>>> formation, and that should be off by default.
>>> 
>>> We can have it off by default. In the name of having a uniform
>>> policy which defaults to IEEE compliance, that's fine, and I can
>>> explain that to my users, etc. We should also document this
>>> prominently on the clang web page (especially if this differs from
>>> gcc's default behavior).
>> 
>> FWIW, this will lower amateur benchmark scoring runs. (e.g. Phoronix).
>> 
>> Strict IEEE conformance is far less likely to be desired than fast
>> code. In my experience, the only users who want strict conformance are
>> the authors of math libraries and the occasional application like ray
>> tracing where denormals are common.
> 
> FWIW, as I've stated previously, I agree with this. The consensus on
> this list (I think) has been in favor of strict conformance by
> default. Given that, I favor consistency across all platforms. Having
> strict conformance by default on some platforms and not on others, I
> think, will be even more confusing than having a uniform rule.

The only users who *want* strict conformance are the authors of math libraries and numerical applications.  However, *all* users benefit from a more predictable and correct numerics model, whether they know about it or not.  Unpredictable numerics models and performance "optimizations" that come at the cost of correctness only further the popular perception that floating-point is black magic / non-deterministic / otherwise incomprehensible by mortals.

clang/llvm have historically been fairly strict numerically by default, while still delivering good performance.  I don't see any reason to give that up; correctness is much more compelling than amateur benchmarks.

There's nothing wrong with having modes that users can opt-into that enable all sorts of numerical chicanery, but they should not be the default.

- Steve



More information about the llvm-commits mailing list