[llvm-commits] [llvm] r107904 - in /llvm/trunk: lib/Target/ARM/ARMISelLowering.cpp test/CodeGen/ARM/fpcmp-opt.ll

John McCall rjmccall at apple.com
Fri Jul 9 21:26:19 PDT 2010


On Jul 8, 2010, at 11:30 PM, Chris Lattner wrote:

> On Jul 8, 2010, at 10:27 PM, Evan Cheng wrote:
> On Jul 8, 2010, at 1:15 PM, Chris Lattner wrote:
>>> 
>>> On Jul 8, 2010, at 1:12 PM, Evan Cheng wrote:
>>> 
>>>> Author: evancheng
>>>> Date: Thu Jul  8 15:12:24 2010
>>>> New Revision: 107904
>>>> 
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=107904&view=rev
>>>> Log:
>>>> Check for FiniteOnlyFPMath as well.
>>> 
>>> Evan, this xform is not target specific.  Is there any reason not to implement it in dag combine?
>> 
>> It's profitable on ARM because it requires a vmrs which is expensive. I am not sure if other targets can benefit from it. I am also extending it to support f64 case which may have huge benefit for certain flavors of ARM.
> 
> I don't know of any target where an fp compare is cheaper than an int compare.  (compare (load), (load)) is similar to the "store of fp immediate" which we transform into an integer immediate in target independent code.
> 
>>> It also seems really dangerous to me, even for -ffast-math.
>> 
>> That's why it's only one with -funsafe-math-optimizations. Are there other issues apart from the -0.0 and Nan?
> 
> -0.0 and NaN are pretty significant.  There is also denormals which may or may not be a problem if the value isn't normalized (I don't know).

Denormals aren't a problem for most representations because the denormal range doesn't intersect the normal range, but they'd break the transformation pretty hard for x87 long doubles (for multiple reasons).  Of course, there's no 80-bit integer comparison anyway.

John.



More information about the llvm-commits mailing list