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?
+/* (v ? w : 0) ? a : b is just (v & w) ? a : b */
+(simplify
+ (vec_cond (vec_cond:s @0 @3 integer_zerop) @1 @2)
+ (vec_cond (bit_and @0 @3) @1 @2))
Does something check automatically that @0 and @3 have compatible types?
My memory of this dates from before the avx512-related changes, but at
least at the time, the type of the condition in vec_cond_expr had to have
the same size and number of elements as the result, and have signed
integral elements. Now the size constraint has changed, but it still looks
like for a given number of elements and size (this last one ignored for
avx512), there is essentially a single type that can appear as condition.
Is this wrong for x86? For SVE?
I could add some types_match conditions if that seems too unsafe...
--
Marc Glisse
