[PATCH] Fix floating point handling in dom (PR tree-optimization/84235)

[Jeff Law]

On 02/07/2018 12:06 AM, Richard Biener wrote:
> On February 6, 2018 9:40:37 PM GMT+01:00, Jakub Jelinek <jakub@redhat.com> wrote:
>> Hi!
>>
>> As the following testcase shows, dom2 miscompiles floating point x - x
>> into 0.0 even when x could be infinity and x - x then a NaN.
>> The corresponding match.pd optimization is:
>> /* Simplify x - x.
>>   This is unsafe for certain floats even in non-IEEE formats.
>>   In IEEE, it is unsafe because it does wrong for NaNs.
>>   Also note that operand_equal_p is always false if an operand
>>   is volatile.  */
>> (simplify
>> (minus @0 @0)
>> (if (!FLOAT_TYPE_P (type) || !HONOR_NANS (type))
>>  { build_zero_cst (type); }))
>> The patch makes it match what match.pd does.
>> We also have:
>> /* X / X is one.  */
>> (simplify
>>  (div @0 @0)
>> /* But not for 0 / 0 so that we can get the proper warnings and errors.
>>     And not for _Fract types where we can't build 1.  */
>>  (if (!integer_zerop (@0) && !ALL_FRACT_MODE_P (TYPE_MODE (type)))
>>   { build_one_cst (type); }))
>> We can ignore the 0 / 0 case, we have both operands SSA_NAMEs and
>> match.pd
>> only avoids optimizing away literal 0 / 0, but the rest is valid, some
>> fract
>> types don't have a way to express 1.
>>
>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> OK. 
> 
> I wonder why we have to re-implement all this in DOM. there's enough of match and simplify interfaces to make it use that? 
What's going on with this code is we have some kind of binary
expression.  We do not know the value of either operand.

However, we have recorded that the two operands are equal to each other
via a conditional equivalence.  ie, we have 1 = (A == B) in the
expression hash table.

For many binary operations knowing the operands are equal allows us to
eliminate the binary operation.

This was part of avoiding regressing when we stopped recording
conditional equivalences in the cprop tables.

What I'm concerned about here is how did we get into this code for a
floating point object  That should have been filtered out earlier!


Jeff