match.pd: Avoid other build_nonstandard_integer_type calls [PR111369]

match.pd: Avoid other build_nonstandard_integer_type calls [PR111369]

In the light of the PR111668 patch which shows that
build_nonstandard_integer_type is needed (at least for some signed prec > 1
BOOLEAN_TYPEs if we use e.g. negation), I've reworked this patch and handled
the last problematic build_nonstandard_integer_type call in there as well.

In the x == cstN ? cst4 : cst3 optimization it uses
build_nonstandard_integer_type solely for BOOLEAN_TYPEs (I really don't see
why ENUMERAL_TYPEs would be a problem, we treat them in GIMPLE as uselessly
convertible to same precision/sign INTEGER_TYPEs), for INTEGER_TYPEs it is
really a no-op (might return a different type, but always INTEGER_TYPE
with same TYPE_PRECISION same TYPE_UNSIGNED) and for BITINT_TYPE with larger
precisions really harmful (we shouldn't create large precision
INTEGER_TYPEs).

The a?~t:t optimization just omits the negation of a in type for 1-bit
precision types or any BOOLEAN_TYPEs.  I think that is correct, because
for both signed and unsigned 1-bit precision type, cast to type of a bool
value yields already 0, -1 or 0, 1 values and for 1-bit precision negation
of that is still 0, -1 or 0, 1 (except for invoking sometimes UB).
And for signed larger precision BOOLEAN_TYPEs I think it is correct as well,
cast of [0, 1] to type yields 0, -1 and those can be xored with 0 or -1
to yield the proper result, any other values would be UB.

This fixes PR111369, where one of the bitint*.c tests FAILs with
GCC_TEST_RUN_EXPENSIVE=1.

2023-10-04  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/111369
	* match.pd (x == cstN ? cst4 : cst3): Use
	build_nonstandard_integer_type only if type1 is BOOLEAN_TYPE.
	Fix comment typo.  Formatting fix.
	(a?~t:t -> (-(a))^t): Always convert to type rather
	than using build_nonstandard_integer_type.  Perform negation
	only if type has precision > 1 and is not signed BOOLEAN_TYPE.