On Tue, 5 Mar 2019, Richard Sandiford wrote: > Jakub Jelinek <ja...@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.
