VEC_COND_EXPR optimizations

Marc Glisse marc.glisse@inria.fr
Fri Jul 31 13:13:11 GMT 2020


On Fri, 31 Jul 2020, Marc Glisse wrote:

> On Fri, 31 Jul 2020, Richard Sandiford wrote:
>
>> Marc Glisse <marc.glisse@inria.fr> writes:
>>> 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?
>> 
>> 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.

That was for rounding. -ftrapping-math does not disable folding of

typedef double vecf __attribute__((vector_size(16)));
typedef long long veci __attribute__((vector_size(16)));
vecf f(veci c){
     vecf z={};
   return (z+1)/(z+3);
}

despite a possible inexact flag, so it doesn't disable vec_cond_expr 
folding either.

(not sure we want to fix this unless -fno-trapping-math becomes the 
default)

-- 
Marc Glisse


More information about the Gcc-patches mailing list