Re: VEC_COND_EXPR optimizations

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

On Fri, 31 Jul 2020, Richard Sandiford wrote:

> Marc Glisse <marc.glisse@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