[PATCH] Guard binary/ternary match.pd patterns to IFN_COND_* with IFN_COND_* availability (PR tree-optimization/89570)

[Richard Sandiford]

Jakub Jelinek <jakub@redhat.com> writes:
> Hi!
>
> As the following testcase shows, these match.pd patterns create temporary
> GIMPLE stmts even when they aren't going to result in anything useful
> (all targets except aarch64 right now), besides compile time memory
> this is bad with -fno-tree-dce because those stmts might not be even valid
> for the target and we might ICE during expansion.
>
> Fixed by guarding them with a vectorized_internal_fn_supported_p test.
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Note, I have no idea how to test this on aarch64, Richard S., can you please
> do that?  Thanks.

Sorry, commented on the bug before seeing this patch.

I don't think this is the way to go though.  If we want match.pd
rules to have early checks for whether an ifn is supported, I think we
should get genmatch to do that itself rather than have to remember
to do it manually for each match.pd condition.

In this case, isn't the underying problem that we only support some
vector conditions in VEC_COND_EXPRs and not as stand-alone comparisons?
Shouldn't we address that directly and then treat the early checks as
a separate compile-time optimisation?

As far as the patch itself goes, I don't understand why you have:

      internal_fn cond_fn = get_conditional_internal_fn (uncond_op); }

when the cond_op iterator already gives the conditional internal function.

Actually... I see this went while writing the email, but it still seems
like the wrong approach to me.

Thanks,
Richard