Re: Propagation of "pointer" attribute on registers

[Jeffrey A Law <law at redhat dot com>]

On Fri, 2005-02-18 at 13:28 -0600, Pat Haugen wrote:
> 
> 
> 
> Is there a reason REG_POINTER isn't propagated to the target register for
> rtl insns of the form "reg_x = regP_y + reg_z", where regP_y is a reg
> marked as REG_POINTER?  It seems the attribute is only propagated when we
> have "reg_x = regP_y + CONST", at least in the couple instances I saw
> (regclass.c:reg_scan_mark_refs() and explow.c:memory_address()).  I've run
> across a case where lack of the REG_POINTER attribute is causing global PRE
> to miss a hoisting opportunity since a memory reference no longer looks
> available (memory disambiguation fails in alias.c:base_alias_check() since
> we can't determine the base address of the memory reference).
It could well be an oversight.  Though as I believe Jim mentioned, you
have to be careful due to architectures like the PA and mn103 where
it's critical to be able to distinguish between a pointer into an
object, a pointer outside of an object and an index.

Consider for example

char a[10];

x1 = &a[0];
x2 = x1 - 10;
y1 = 11;
*(x2 + y) = 20;


x1 is a pointer into an object
x2 is a pointer outside the object
y1 is an index

The problems arise when we try to use unscaled indexed addressing modes;
on some architectures (PA, mn103) memory references implicitly select a
memory segment based on the index register _NOT_ the effective address.

So if "a" in the example above was at the start of the segment boundary
and we used an unscaled indexed address for *(x2 + y), then we would
access the wrong segment and segfault.


ie, setting REG_POINTER needs to be conservatively correct for the
destination of arithmetic insns.

Note there's a number of improvements that could be made to how we
generate and propagate REG_POINTER.

jef