| Message ID | 8760no3e9u.fsf@e105548-lin.cambridge.arm.com |
|---|---|
| State | New |
| Headers | show |
On 11/15/2016 09:21 AM, Richard Sandiford wrote: > If the size passed in to rtx_addr_can_trap_p was zero, the frame > handling would get the size from the mode instead. However, this > too can be zero if the mode is BLKmode, i.e. if we have a BLKmode > memory reference with no MEM_SIZE (which should be rare these days). > This meant that the conditions for a 4-byte access at offset X were > stricter than those for an access of unknown size at offset X. > > This patch checks whether the size is still zero, as the > SYMBOL_REF handling does. > > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? > > Thanks, > Richard > > > [ This patch is part of the SVE series posted here: > https://gcc.gnu.org/ml/gcc/2016-11/msg00030.html ] > > gcc/ > 2016-11-15 Richard Sandiford <richard.sandiford@arm.com> > Alan Hayward <alan.hayward@arm.com> > David Sherwood <david.sherwood@arm.com> > > * rtlanal.c (rtx_addr_can_trap_p_1): Handle unknown sizes. I guess it's conservatively correct in that claiming we can trap when we can't never hurts correctness. I'm OK with the patch, but am quite curious how we got to this point without an attached MEM_SIZE. jeff
Jeff Law <law@redhat.com> writes: > On 11/15/2016 09:21 AM, Richard Sandiford wrote: >> If the size passed in to rtx_addr_can_trap_p was zero, the frame >> handling would get the size from the mode instead. However, this >> too can be zero if the mode is BLKmode, i.e. if we have a BLKmode >> memory reference with no MEM_SIZE (which should be rare these days). >> This meant that the conditions for a 4-byte access at offset X were >> stricter than those for an access of unknown size at offset X. >> >> This patch checks whether the size is still zero, as the >> SYMBOL_REF handling does. >> >> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? >> >> Thanks, >> Richard >> >> >> [ This patch is part of the SVE series posted here: >> https://gcc.gnu.org/ml/gcc/2016-11/msg00030.html ] >> >> gcc/ >> 2016-11-15 Richard Sandiford <richard.sandiford@arm.com> >> Alan Hayward <alan.hayward@arm.com> >> David Sherwood <david.sherwood@arm.com> >> >> * rtlanal.c (rtx_addr_can_trap_p_1): Handle unknown sizes. > I guess it's conservatively correct in that claiming we can trap when we > can't never hurts correctness. > > > I'm OK with the patch, but am quite curious how we got to this point > without an attached MEM_SIZE. Yeah, I should have kept better notes... This didn't show up on SVE itself, but was something I tripped over while doing the before-and-after comparison of assembly output on other targets. A later patch in the SVE series removes: if (size == 0) size = GET_MODE_SIZE (mode); on the basis that if a meaningful mode size was available, the caller would have passed it in as the size parameter. However, that tripped over the fact that, when the mode was BLKmode, we would treat the size of 0 literally. This in turn meant that that later patch caused minor codegen changes on other targets. Thanks, Richard
diff --git a/gcc/rtlanal.c b/gcc/rtlanal.c index a9d3960..889b14d 100644 --- a/gcc/rtlanal.c +++ b/gcc/rtlanal.c @@ -543,6 +543,8 @@ rtx_addr_can_trap_p_1 (const_rtx x, HOST_WIDE_INT offset, HOST_WIDE_INT size, if (size == 0) size = GET_MODE_SIZE (mode); + if (size == 0) + return 1; if (x == frame_pointer_rtx) {