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
