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

Richard Biener rguenther@suse.de
Tue Mar 5 09:26:00 GMT 2019


On Tue, 5 Mar 2019, Richard Sandiford wrote:

> 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.

But vector IFNs/operations are special (unfortunately).  Look how
we need to check for valid constant permutations for example.

> 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.

Richard.



More information about the Gcc-patches mailing list