[cfe-dev] Complex arithmetic ignores -ffast-math after clang r219557, serious performance regressions

[Richard Campbell]

Hal,

SVN now seems to be respecting the -ffast-math flag in the way we desire without Matthijs’ temporary fix. I didn’t see any further traffic about this on the cfe-dev list - was there a discussion elsewhere? Did it get fixed by accident as part of some other change, and we should worry about whether it will come up again?

Richard

> On Jul 2, 2015, at 2:45 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> Hi Richard,
> 
> Thanks for bringing this to my attention.
> 
> -Hal
> 
> ----- Original Message -----
>> From: "Richard Campbell" <rlcamp.pdx at gmail.com>
>> To: hfinkel at anl.gov
>> Sent: Wednesday, July 1, 2015 12:13:50 PM
>> Subject: Fwd: Complex arithmetic ignores -ffast-math after clang r219557, serious performance regressions
>> 
>> Hal,
>> 
>> 
>> I posted this in the cfe-dev mailing list about a week ago and didn’t
>> get any replies. Can you comment on this or recommend another more
>> ideal place to discuss it?
>> 
>> 
>> Richard Campbell
>> 
>> 
>> 
>> 
>> Begin forwarded message:
>> 
>> From: Richard Campbell < rlcamp.pdx at gmail.com >
>> 
>> Subject: Complex arithmetic ignores -ffast-math after clang r219557,
>> serious performance regressions
>> 
>> Date: June 25, 2015 at 11:54:10 AM PDT
>> 
>> To: cfe-dev at cs.uiuc.edu
>> 
>> 
>> 
>> 
>> After building with clang 3.7svn recently, I saw a huge speed hit
>> across much of our HPC and floating point DSP code. I looked at the
>> asm output and it's riddled with calls to ___mulsc3, which is never
>> inlined (preventing lots of other optimizations) and which includes
>> a bunch of C99 Annex G-recommended branch conditions for range
>> checks and whatnot. One of the purposes of -ffast-math has always
>> been to disable these sort of checks, trusting the developer to
>> ensure that they can't happen or will be handled upstream.
>> 
>> 
>> Explicitly writing out the real and imaginary component math in one
>> of my critical sections was enough to confirm that the problem lies
>> here and not elsewhere. However, doing this throughout all of our
>> code would be prohibitive, and of course greatly reduces the
>> readability of the code and presumably the ability for future
>> compilers to optimize it in a way that I haven’t though of yet.
>> 
>> 
>> The relevant patch discussion in the mailing list is here:
>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20141006/116248.html
>> and includes a comment from hfinkel also requesting that the
>> libcalls be skipped in fast-math mode. From what I can see there was
>> no followup on this.
>> 
>> 
>> At the bare minimum I think these checks should be disabled within
>> mulsc3 when ffast-math or the relevant subflag is enabled, and
>> preferably that the library calls be skipped entirely as before, so
>> that other compiler optimizations aren't prevented.
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory