Re: [GCC][middle-end] Add rules to strip away unneeded type casts in expressions (2nd patch)

[Marc Glisse <marc.glisse@inria.fr>]

On Mon, 7 Jan 2019, Tamar Christina wrote:

> The 01/04/2019 17:50, Marc Glisse wrote:
>>> +	     (convert:newtype (op (convert:newtype @1) (convert:newtype @2)))
>>
>> The outer 'convert' is unnecessary, op already has the same type.
>>
>
> Does it? The only comparison that has been done between the type of op and "type" is that
> they are both a decimal floating point type. I don't see any reason why they have to be the
> same type.

op is just PLUS_EXPR (or another operation), it isn't related to @0, it 
does not have a type in itself. When you build the sum of 2 objects of 
type newtype, the result has type newtype. On the other hand, if newtype 
is not the same as type, you may be missing a conversion of the result to 
type. Ah, I see that newtype is always == type here.

>>> +	    (nop:type (op (convert:ty1 @1) (convert:ty2 @2)))))
>>
>> Please don't use 'nop' directly, use 'convert' instead. This line is very
>> suspicious, both arguments of op should have the same type. Specifying the
>> outertype should be unnecessary, it is always 'type'. And if necessary, I
>> expect '(convert:ty1 @1)' is the same as '{ arg0; }'.
>>
>
> Ah I wasn't aware I could use arg0 here. I've updated the patch, though I don't
> really find this clearer.

> + (convert (op (convert:ty1 { arg0; }) (convert:ty2 { arg1; })))))

I think you misunderstood my point. What you wrote is equivalent to:

 	(convert (op { arg0; } { arg1; }))))

since arg0 already has type ty1. And I am complaining that both arguments 
to op must have the same type, but you are creating one of type ty1 and 
one of type ty2, which doesn't clearly indicate that ty1==ty2.

Maybe experiment with
(long double)some_float * (long double)some_double
cast to either float or double.

SCALAR_FLOAT_TYPE_P may be safer than FLOAT_TYPE_P.

-- 
Marc Glisse