https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The #c9 patch looks good, but I don't view #c5 as papering over issues, but
rather as an optimization and desirable change.
The expansion of ARRAY_REFs is done through calling get_inner_reference and
expanding the base and offset.
And, get_inner_reference does with the index:
offset = size_binop (PLUS_EXPR, offset,
size_binop (MULT_EXPR,
fold_convert (sizetype, index),
unit_size));
so, all upper bits beyond TYPE_PRECISION (sizetype) are thrown away.
While it is probably desirable for optimization purposes to keep ARRAY_REF
indexes with smaller or equal precision than sizetype in whatever type they
were originally, I don't see any advantages of pretending we care about the
extra bits we ignore in the end, by folding it during gimplification we might
generate better code by computing stuff only in narrower types etc.
Given above, I'm no longer worried about what it would cause for targets with
weird pointer sizes.
BTW, e.g. get_addr_base_and_unit_offset_1 doesn't seem to be prepared to handle
ARRAY_REF indexes larger than sizetype:
poly_offset_int woffset
= wi::sext (wi::to_poly_offset (index)
- wi::to_poly_offset (low_bound),
TYPE_PRECISION (TREE_TYPE (index)));
While offset_int is actually 128-bit for efficiency, if we use the full
sometimes signed, sometimes unsigned __int128 indexes there, we don't have the
always signed bit anyway. Guess the above could be easily changed to
MIN (TYPE_PRECISION (TREE_TYPE (index)), TYPE_PRECISION (sizetype)) or similar,
but with the gimplifier change it wouldn't be needed (we could later on add
verifier that ARRAY*REF indexes aren't wider than sizetype's precision).
