i386: Fix up *testqi_ext_3 define_insn_and_split [PR94567]

i386: Fix up *testqi_ext_3 define_insn_and_split [PR94567]

As the testcase shows, there are unfortunately more problematic cases
in *testqi_ext_3 if the mode is not CCZmode, because the sign flag might
not behave the same between the insn with zero_extract and what we split it
into.

The previous fix to the insn condition was because *testdi_1 for mask with
upper 32-bits clear and bit 31 set is implemented using SImode test and thus
SF is set depending on that bit 31 rather than on always cleared.

But we can have other cases.  On the zero_extract (which has <MODE>mode),
we can have either the pos + len == precision of <MODE>mode, or
pos + len < precision of <MODE>mode cases.  The former one copies the most
significant bit into SF, the latter will have SF always cleared.

For the former case, either it is a zero_extract from a larger mode, but
then when we perform test in that larger mode, SF will be always clear and
thus mismatch from the zero_extract case (so we need to enforce CCZmode),
or it will be a zero_extract from same mode with pos 0 and len equal to
mode precision, such zero_extracts should have been really simplified
into their first operand.

For the latter case, when SF is always clear on the define_insn with
zero_extract, we need to split into something that doesn't sometimes set
SF, i.e. it has to be a test with mask that doesn't have the most
significant bit set.  In some cases it can be achieved through using test
in a wider mode (e.g. in the testcase, there is
(zero_extract:SI (reg:HI) (const_int 13) (const_int 3))
which will always set SF to 0, but we split it into
(and:HI (reg:HI) (const_int -8))
which will copy the MSB of (reg:HI) into SF, but we can do:
(and:SI (subreg:SI (reg:HI) 0) (const_int 0xfff8))
which will keep SF always cleared), but there are various cases where we
can't (when already using DImode, or when SImode and we'd turned it into
the problematic *testdi_1 implemented using SImode test, or when
the val operand is a MEM (we don't want to read from memory more than
the user originally wanted), paradoxical subreg of MEM could be problematic
too if we through the narrowing end up with a MEM).

So, the patch attempts to require CCZmode (and not CCNOmode) if it can't
really ensure the SF will have same meaning between the define_insn and what
we split it into, and if we decide we allow CCNOmode, it needs to avoid
performing narrowing and/or widen if pos + len would indicate we'd have MSB
set in the mask.

2020-04-17  Jakub Jelinek  <jakub@redhat.com>
	    Jeff Law  <law@redhat.com>

	PR target/94567
	* config/i386/i386.md (*testqi_ext_3): Use CCZmode rather than
	CCNOmode in ix86_match_ccmode if len is equal to <MODE>mode precision,
	or pos + len >= 32, or pos + len is equal to operands[2] precision
	and operands[2] is not a register operand.  During splitting perform
	SImode AND if operands[0] doesn't have CCZmode and pos + len is
	equal to mode precision.

	* gcc.c-torture/execute/pr94567.c: New test.

Co-Authored-By: Jeff Law <law@redhat.com>