Re: proposed patch for gcse.c (delete_null_pointer_checks)

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

  In message <19991028081526L.mitchell@codesourcery.com>you write:
  > More worrisome, in this case, is that I can imagine the compiler doing
  > this stuff: you write:
  > 
  >   int *p = (int*) 4; /* This is an I/O port.  */
  >   (*p) = 3;
  > 
  > and, for some reason, it ends up in RTL at some point as:
  > 
  >   int *p = 0;
  >   *(p + 4) = 3;
  > 
  > I can imagine cases where the compiler doing this would make sense,
  > even though the second program would be invalid C if written directly.
Precisely.  This is exactly why I'm arguing against the extension to the
existing optimization.  It's not valid C if the user writes it, but the
compiler does make these kinds of transformations and we have the potential
to incorrectly optimize user code.

I know about this stuff because I happen to work on an architecture that is
highly sensitive to these kinds of transformations.

The PA is a segmented architecture, and most memory accesses implicitly select
which segment to use.  All addresses are of the form basereg + indexreg or
basereg + immediate.  Segment selection is done strictly by the value in
basereg, not the effective address.

So, if we had a pointer P and derived some P'; we have to be careful that the
value for P & P' would result in the same segment selection in a memory
address.  It sucks in a major way since in a memory reference

(plus (reg 0) (reg 1)) != (plus (reg 1) (reg 0)


jeff