On Tue, Sep 05, 2023 at 03:07:15PM -0700, Andrew Pinski wrote:
> Note I notice another all to build_nonstandard_integer_type in this
> match pattern which might also need to be fixed:
> /* For (x << c) >> c, optimize into x & ((unsigned)-1 >> c) for
> unsigned x OR truncate into the precision(type) - c lowest bits
> of signed x (if they have mode precision or a precision of 1). */
> (simplify
> (rshift (nop_convert? (lshift @0 INTEGER_CST@1)) @@1)
> (if (wi::ltu_p (wi::to_wide (@1), element_precision (type)))
> (if (TYPE_UNSIGNED (type))
> (bit_and (convert @0) (rshift { build_minus_one_cst (type); } @1))
> (if (INTEGRAL_TYPE_P (type))
> (with {
> int width = element_precision (type) - tree_to_uhwi (@1);
> tree stype = build_nonstandard_integer_type (width, 0);
> }
> (if (width == 1 || type_has_mode_precision_p (stype))
> (convert (convert:stype @0))))))))
>
> Do we have ranges on BITINT_TYPEs? If so the two_value_replacement
> pattern in match.pd has a similar issue too.
> (that is where I copied the code to use build_nonstandard_integer_type
> from originally too.
BITINT_TYPEs do have ranges like any other integral types. But the larger
ones should be lowered shortly after IPA and arithmetics etc. on them
shouldn't appear in later passes.
Most BITINT_TYPEs or for the above cases overly large INTEGER_TYPEs
will not satisfy type_has_mode_precision_p (but it isn't a good idea
to create such types only to throw them away).
But some BITINT_TYPEs do have non-BLKmode TYPE_MODE, they follow what modes
get similarly sized structures, so on some targets one could get OImode or
XImode. For the above case, I think we definitely don't want to emit
integral types with such modes because nothing during expansion will support
them. So, I wonder if the above shouldn't do
tree stype = NULL_TREE;
if (width <= (targetm.scalar_mode_supported_p (TImode)
? TImode : DImode))
stype = build_nonstandard_integer_type (width, 0);
and || (stype && type_has_mode_precision_p (stype)))
so that we don't create types which wouldn't work.
Jakub
