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
