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

Hal Finkel hfinkel at anl.gov
Wed Jun 20 09:53:17 PDT 2012


On Tue, 19 Jun 2012 16:36:19 -0400
Stephen Canon <scanon at apple.com> wrote:

> 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.

FWIW, now that FMA formation is not on by default,
SingleSource/Benchmarks/Misc-C++/Large/sphereflake executes 14% slower
(on POWER7) and also does not pass. gcc uses fma's by default, and when
we do too, we get the same answer. Now that we don't, we get a different
answer.

Is there a way to have gcc not use fma's so that we can again have a
direct comparison? I know that IBM's compiler has a strict option, but
I don't see anything in the gcc manual that is similar (I see options
for ieee compliance that are target specific, but nothing under
powerpc; is there something general?).

Thanks again,
Hal

> 
> 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



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-commits mailing list