[cfe-commits] [PATCH] Add -fexcess-precision option.

[Stephen Canon]

On Jun 21, 2012, at 3:27 AM, Chandler Carruth <chandlerc at google.com> wrote:

> The flag semantics '-fexcess-precision' (as spec'ed for GCC) don't seem to map clearly onto this use case, especially as John argued so effectively in the previous email thread. I feel like this flag should remain very specifically attached to FP operations with more bits, but none of the asymmetrical properties of FMAs, so that there is no confusion between Clang's semantics and GCC's.

A minor point: GCC "excess precision" introduces exactly the same asymmetries as does FMA in the presence of spill-fill or common subexpression elimination.

Consider an expression like a*b - c*d with a = c and b = d.  If computed entirely in excess precision, there is no asymmetry.  However, if a*b is either eliminated or computed earlier and spilled in native precision, then it is rounded to native precision before the subtraction, whereas the product c*d may not be; this is exactly the same asymmetry that occurs from using FMA.

That said, I don't love overloading excess-precision for this, even if fma is formally a special case of excess precision, mostly because excess precision has even more bizarre corner cases -- it leads to such monstrosities as cos(x) != cos(x).

> I'd suggest a new flag without any baggage, and one that perhaps ties more closely into the idea of contracted expressions, or some other concept intrinsic to fusing operations. Maybe '-fcontract-expressions={fast,standard,strict}'? Dunno. Naming things is hard.


Relating the flag to contracted expressions is probably wrong; contracted expressions has a specific meaning in the C standard, which is not the same as liberal (cross-expression) FMA formation.  As you say, naming things is hard.  If we're not going to use excess-precision, I would suggest a name that is completely explicit; something along the lines of -fallow-fma-anywhere or -fallow-fma-across-expressions (those might be too wordy).

- Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120621/5e279fc1/attachment.html>