On Fri, 31 Jul 2020, Richard Sandiford wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
On Fri, 31 Jul 2020, Richard Sandiford wrote:
Marc Glisse <marc.gli...@inria.fr> writes:
+/* (c ? a : b) op (c ? d : e) --> c ? (a op d) : (b op e) */
+ (simplify
+ (op (vec_cond:s @0 @1 @2) (vec_cond:s @0 @3 @4))
+ (with
+ {
+ tree rhs1, rhs2 = NULL;
+ rhs1 = fold_binary (op, type, @1, @3);
+ if (rhs1 && is_gimple_val (rhs1))
+ rhs2 = fold_binary (op, type, @2, @4);
+ }
+ (if (rhs2 && is_gimple_val (rhs2))
+ (vec_cond @0 { rhs1; } { rhs2; })))))
+#endif
This one looks dangerous for potentially-trapping ops.
I would expect the operation not to be folded if it can trap. Is that too
optimistic?
Not sure TBH. I was thinking of “trapping” in the sense of raising
an IEEE exception, rather than in the could-throw/must-end-bb sense.
That's what I understood from your message :-)
I thought match.pd applied to things like FP addition as normal and
it was up to individual patterns to check the appropriate properties.
Yes, and in this case I am delegating that to fold_binary, which already
performs this check.
I tried with this C++ program
typedef double vecf __attribute__((vector_size(16)));
typedef long long veci __attribute__((vector_size(16)));
vecf f(veci c){
return (c?1.:2.)/(c?3.:7.);
}
the folding happens by default, but not with -frounding-math, which seems
like exactly what we want.
--
Marc Glisse
