On Fri, Jul 31, 2020 at 1:39 PM Marc Glisse <marc.gli...@inria.fr> wrote:
>
> 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?
@0 should always have a vector boolean type and thus will not be generally
compatible with @3. But OTOH then when you see (vec_cond (vec_cond ...
then @3 must be vector boolean as well...
But in theory with AVX512 the inner vec_cond could have a SImode
condition @0 producing a regular V4SImode vector mask for an outer
AVX512 SSE-style vec-cond and you then would get a mismatch.
So indeed better add a type compatibility check.
> 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
