https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org,
| |jakub at gcc dot gnu.org,
| |uros at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> There's also
>
> && ix86_match_ccmode (insn,
> /* *testdi_1 requires CCZmode if the mask has bit
> 31 set and all bits above it clear. */
> GET_MODE (operands[2]) == DImode
> && INTVAL (operands[3]) + INTVAL (operands[4]) == 32
> ? CCZmode : CCNOmode)"
>
> which is likely where the original correctness issue lies - it fails
> to check for the similar cases and HImode (and SImode and QImode).
At least in my understanding of this PR, the above addition in PR94088 isn't
where the problem is, but the problem is that we shouldn't require CCZmode just
in that case, but also in other cases where the splitting would change the
meaning of the sign flag.
If (GET_MODE_PRECISION (<MODE>mode) < INTVAL (operands[3])), then the unsplit
pattern will have SF always false, so we need to ensure that either the pattern
is using CCZmode in which case we don't care about the sign, or that the mask
we'll use doesn't have the most significant bit set.
If (GET_MODE_PRECISION (<MODE>mode) == INTVAL (operands[3])), then the SF will
be equal to the most significant bit before splitting. But then we'd need the
resulting insn to use that exact mode, which would mean only trivial zero
extraction from position 0 and all bits, combiner should have simplified that
IMNSHO.
