Fix handling of unknown sizes in rtx_addr_can_trap_p

Fix handling of unknown sizes in rtx_addr_can_trap_p

[Richard Sandiford]

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.

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)
 	    {

Re: Fix handling of unknown sizes in rtx_addr_can_trap_p

[Jeff Law]

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

Re: Fix handling of unknown sizes in rtx_addr_can_trap_p

[Richard Sandiford]

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