Jakub Jelinek <ja...@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 <ja...@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
