[PATCH] [complex] Teach the complex math IR gen to emit direct math and a NaN-test prior to the call to the library function.

[Hal Finkel]

----- Original Message -----
> From: "Steve Canon" <scanon at apple.com>
> To: chandlerc at gmail.com, resistor at mac.com, hfinkel at anl.gov, scanon at apple.com
> Cc: cfe-commits at cs.uiuc.edu
> Sent: Friday, October 17, 2014 4:23:28 AM
> Subject: Re: [PATCH] [complex] Teach the complex math IR gen to emit direct math and a NaN-test prior to the call to
> the library function.
> 
> Apologies for delay in looking at this, I'm on vacation this week.
> 
> I don't love this approach because (a) it doesn't get us fully to
> where we want to be in performance, and (b) it's going to trash the
> floating-point flag state.  The performance issue is that we still
> have two comparisons and one or two branches for every complex op
> outside of no-nans, and the flags issue is as follows:
> 
> The intention of IEEE-754 is that anything that is conceptually a
> single "operation" should raise at most one of divide-by-zero,
> invalid, overflow, or underflow.  A complex multiplication
> implemented with lazy checking may cause two of these to be raised:
> 
>     (tiny, huge) * (tiny, huge) --> underflow + overflow
>     (0, huge) * (inf, huge) --> invalid + overflow, no flags

Thinking about this, this can only matter if we actually permit access to the FP environment, which we currently don't. So, if we were to ever allow "#pragma STDC FENV_ACCESS on", then we'd want to disable this optimization. But for now this is irrelevant (at least from the C perspective). Is this right?

 -Hal

> 
> My preferred approach would be to implement limited-range semantics
> as an option (via either pragma or flag), and have it implied by
> fast-math.
> 
> Now, all that being said, I haven't checked if today's compiler-rt
> implementations are even correct w.r.t. flags in this sense, so it's
> not immediately obvious that this change makes anything worse today,
> and it will address //some// of the performance concerns of the
> earlier patch.  It just seems contrary to the direction that we
> really want to be going in the longer-term w.r.t. numerical
> correctness.
> 
> http://reviews.llvm.org/D5756
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory