https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123268
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Robin Dapp from comment #2)
> It's the following match.pd pattern that fre happens to invoke:
>
> /* Transform x * { 0 or 1, 0 or 1, ... } into x & { 0 or -1, 0 or -1, ...},
> unless the target has native support for the former but not the latter.
> */
> (simplify
> (mult @0 VECTOR_CST@1)
> (if (initializer_each_zero_or_onep (@1)
> ...
>
> I guess that's via try_conditional_simplification which strips cond, len,
> else, etc. from an IFN and simplifies the underlying operation, then adds it
> back.
>
> We probably don't have too many patterns that go from float to int and this
> particular case where the else value is stale just never happened?
>
> In convert_conditional_op when we put the IFN back together we don't verify
> that the operand types (or orig_op.type) and the else value's type match.
> Maybe we should? Another case where IFN type checking would help :)
>
> On the other hand, the float zero is special and we could convert it to an
> integer zero?
Yeah, but I guess that only works for actual zero? So I'd play safe here.
