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.
I thought match.pd applied to things like FP addition as normal and
it was up to individual patterns to check the appropriate properties.
Thanks,
Richard
