On Wed, Jun 19, 2019 at 01:46:15PM +0100, Richard Sandiford wrote:
> For can_vec_perm_const_p we could either add zeroness information
> to vec_perm_indices or provide it separately (e.g. with tree inputs).
> In the latter case the zeroness could be relayed to
> targetm.vec_perm_const by passing zero rtxes even for queries.
Yeah, I'm not against doing this, it might clean stuff up.
But for start I'd still use the vec_sh[lr]_optab under the hood
in can_vec_perm_const_p, and then we can gradually decide if we want
to convert the targets to use that information too in their target hooks
and whether we'll provide some helper routines for them or not.
vec_sh[rl]_<mode> is right now present in aarch64, alpha, i386, ia64, mips,
rs6000 and s390 backends.
> The patch is adding code to places that would not be patched in the same
> way if we already passed down information about zeroness. So it feels
Note, I've already committed the patch, but it can be improved
incrementally.
> like we're adding back code that we already want to take out again at
> some point, unless we change policy and allow specific optabs for
> common permutes. (I'd be fine with that FWIW.)
Well, that is not entirely true, the code that was added for it would
essentially need to be added either way, just instead of to
tree-vect-generic.c to can_vec_perm_const_p if we still kept the optabs,
or to each of the above 7 backends if we propagated that info down to the
target hooks.
Jakub
