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

Evan Cheng evan.cheng at apple.com
Thu Jul 8 23:45:26 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.

I'll look into it after the ARM specific work is done. Currently brcond / select_cc lowering are all done by target independent code. Also they all create target specific nodes so I am not sure if this really work well in dag combine.

It's also more difficult to test since these options can break tests. I'd prefer to deal with one target at a time.

Evan

> 
>>> 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).
> 
> -Chris





More information about the llvm-commits mailing list