Re: [PATCH][AArch64] Fix symbol offset limit

[Jeff Law <law@redhat.com>]

On 10/12/19 3:56 AM, Richard Sandiford wrote:
> Wilco Dijkstra <Wilco.Dijkstra@arm.com> writes:
>> Hi Richard,
>>
>>> If global_char really is a char then isn't that UB?
>>
>> No why?
> 
> Well, "simple expressions like &global_char + 0xffffff00" made it sound
> like there really was a:
> 
>    extern char global_char;
> 
> Only &global_char and &global_char + 1 are defined in that case.
> I was probably taking the example too literally though.
> 
>> We can do all kinds of arithmetic based on pointers, either using
>> pointer types or converted to uintptr_t. Note that the optimizer
>> actually creates these expressions, for example arr[N-x] can be
>> evaluated as (&arr[0] + N) - x.  So this remains legal even if N is
>> well outside the bounds of the array.
> 
> Yeah, true, and I remember valid "x[n - big_offset]" -> invalid
> "x + big_offset - n" being a problem for MIPS too.  It was one of
> the things offset_within_block_p was helping to avoid.
Multiple targets struggle with this.  PA, mn103 also come to mind
immediately.

[ ... ]

> 
> But more importantly, we can't say definitively that code quality isn't
> affected, only that it wasn't affected for the cases we've looked at.
> People could patch the compiler if the new ranges turn out not to strike
> the right balance for their use cases, but not everyone wants to do that.
Absolutely.  IIRC These kinds of addresses are regularly created for
Ada.  Or at least they were.

One of the concepts that really helped the PA from a codegen standpoint
was to distinguish between pointers which we know point into the object
from those which might point outside the object.  Given that knowledge
we could generate more efficient code for the former (particularly WRT
indexed and scaled indexed address modes) and punt the latter.
REGNO_POINTER_FLAG carries this information.

Jeff