[llvm-commits] [llvm] r169049 - /llvm/trunk/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp

[Pedro Artigas]

Hello All,

Back-end compilers and optimizers should, ideally, be bit accurate when folding floating point expressions. Even in fast math mode  there is no excuse (except maybe for compile time) to not be bit accurate. If the transformation can be implemented in bit accurate mode it really should (like constant folding). Unfortunately some transformations, by their very nature, can only generate benefit when results can change, for those fast math flags should be checked.

That is, I believe overloading fast math flags to say: "you can evaluate this at a different precision regardless" is counterproductive.

Pedro

On Dec 2, 2012, at 9:22 AM, Stephen Canon <scanon at apple.com> wrote:

> On Dec 1, 2012, at 4:38 PM, Owen Anderson <resistor at mac.com> wrote:
> 
>> On Dec 1, 2012, at 5:13 AM, Duncan Sands <baldrick at free.fr> wrote:
>> 
>>> it would be great to have a library that evaluates constant expressions
>>> like log2(something) perfectly, rather than having to do this dance around
>>> whether the host evaluates functions accurately enough.  I think GCC uses
>>> MPFR for this.  In the meantime I suppose we are obliged, as you say, to
>>> restrict to cases we can evaluate exactly.
>> 
>> There's an interesting question in there about whether one should implement "perfect" evaluation, or should try to match the semantics of the target.  I've heard of some vendor compilers that went so far as it embed a simulator for the target platform which they used to do truly accurate target-platform-accurate constant folding.
> 
> The general transformation log2(c * x) --> log2(c) + log2(x) can lead to catastrophic cancellation and change answers quite drastically (specifically, this happens if c*x ~ 1), even if both log2(c) and c*x are evaluated exactly (as is the case when c is a power of two).  Because of this, it should only be performed in fast-math modes where trying to match the semantics of the target should be much less of an issue.
> 
> - Steve
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits