On Thu, Dec 12, 2019 at 09:22:47AM +0000, Richard Sandiford wrote:
> > So there's no whole vector equality RTX but we have to pun to integer
> > modes for that? The eq:SImode would suggest that. Guess we should have
> > used a BImode vector representation...
Probably something like
V2BImode/V4BImode/V8BImode/V16BImode/V32BImode/V64BImode, yes, but I'm
afraid changing it would be extremely hard, all the builtins that take the
masks have int/long long arguments and we already generate terrible code
for the mask registers with various PRs, using a different mode would make
it even worse (but sure, more clear).
> >
> > Can you check whether we have any target with whole vector compare patterns
> > that would break here?
All I can see is both x86 and rs6000 using eq:CC with vector operands
(the former in cbranchv*, the latter in various patterns that set both
vector mode comparison result and CCmode comparison result, and
aarch64 having cbranch even for vector modes, but only in define_expand and
expanding that to ptest which uses UNSPECs.
> I wonder how easy it would be to make the mask registers use
> MODE_VECTOR_BOOL instead of scalar integers... :-)
I'm afraid hard.
> For now I think the safest thing would be to punt, rather than assume
> one thing or the other. simplify_const_relational_operation doesn't
> handle many vector cases anyway, and most interesting optimisations
> like this should happen on gimple, where we know whether the condition
> result is a vector or a scalar.
If it starts being ambiguous somewhere, could we use some target macro or
target hook to decide? We already use various target macros in this code,
e.g. FLOAT_STORE_FLAG_VALUE, VECTOR_STORE_FLAG_VALUE, and if they aren't
defined, we punt.
If we used some macro for this case too, we could punt by default if we see
this case and only if the backend said how to handle vector cmp_mode with
scalar int result we could fold it?
Jakub
