[PATCH] Fix ICE on CONST_WIDE_INT in simplify_immed_subreg (PR rtl-optimization/78526)

[Richard Sandiford]

Jakub Jelinek <jakub@redhat.com> writes:
> Hi!
>
> If we try to simplify a paradoxical subreg of a CONST_WIDE_INT,
> we can ICE, because wi::extract_uhwi doesn't like accessing
> bytes beyond the precision.
>   for (i = 0; i < elem_bitsize; i += value_bit)
>     *vp++ = wi::extract_uhwi (val, i, value_bit);
>   for (; i < elem_bitsize; i += value_bit)
>     *vp++ = extend;
> looks wrong, because the second loop is useless.  But, we actually
> do want the second loop, to handle the paradoxical bytes.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2016-11-25  Jakub Jelinek  <jakub@redhat.com>
>
> 	PR rtl-optimization/78526
> 	* simplify-rtx.c (simplify_immed_subreg): Don't use wi::extract_uhwi
> 	beyond val's precision.
>
> 	* gcc.dg/pr78526.c: New test.

OK, thanks.

I think this is still wrong for modes that are wide enough to use
CONST_WIDE_INT but aren't a multiple of a HWI in size.  In that
case we'll still try to access the integer in a wider precision for the
final iteration of the first loop.  I'm not sure we have any targets
like that though, and either way, I agree this is a strict improvement.

Perhaps we should have extract_uhwi that works for arbitrary bitpos
and width and zero-extends beyond the precision, and an extract_shwi
that does the same but sign-extending beyond the precision?  Then code
like this could use a single loop and could safely access any wide-int
representation (regardless of whether it's stored in sign-extended form).
The extract_*hwi routines would become a bit more expensive though.

Does that sound like an improvement?  If so I'll file a PR.
I might have time before GCC 7 if it qualifies.

Thanks,
Richard