[PATCH] Fix simplify-rtx.c handling of avx512 vector comparisons (PR target/92908)

Richard Biener rguenther@suse.de
Thu Dec 12 15:59:00 GMT 2019


On December 12, 2019 10:53:26 AM GMT+01:00, Jakub Jelinek <jakub@redhat.com> wrote:
>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? 

Ambiguous IL is bad :/  IL semantics dependent on a target hook, too. Just look at SHIFT_COUNT_TRUNCATED... 

Richard. 

 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



More information about the Gcc-patches mailing list