PATCH for bogus loop optimization, part 2

Jeffrey A Law law@cygnus.com
Fri Jul 17 01:00:00 GMT 1998


  In message < 199807170635.XAA01576@smtp.earthlink.net >you write:
  > >>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >     Jeffrey>   In message
  >     Jeffrey> < 199807161744.KAA02710@smtp.earthlink.net >you write:
  >     >> BTW, one way to fix this problem, and retain the optimization,
  >     >> might be along the lines of:
  >     >> 
  >     >> o Pointers can never overflow in a conformant program.
  >     >> (Neither can integers, but people do make use of this
  >     >> wrap-around behavior for integers.)
  >     Jeffrey> Right.  And I believe we assume elsewhere in the compiler
  >     Jeffrey> that a pointer can not overflow.
  > 
  >     >> o Any comparison between pointers should be unsigned.
  >     Jeffrey> I don't think we can assume this though.
  > 
  > OK.  But I'm not quite sure why.  Ah, if the mode of the comparsion is
  > sufficiently much larger than the mode of the pointers, so that signed
  > and unsigned comparison mean the same thing?
Two cases come up most of the time.

Pmode that specifies a mode twice the size of POINTER_SIZE.

Pmode is a partial integer mode (like PSImode, PDImode which has a
maximum size, but we don't know how bit is really is) ) and POINTER_SIZE
is something like 18bits, 24bits, etc.

I don't have concrete evidence that it isn't safe -- it's mostly my
gut telling me something bad would happen if we were to make the
assumption that pointers are always unsigned.


There's also a user interface issue.  Consider a machine which has 
"short" addressing modes in high and lo mem.  Say 0x0 - 0x7f and
0xffffff80 - 0xffffffff.  A user might look at them as short addressing
modes centered around address zero.  ie -128 .. 127   They might even
want to check a pointer value to see if it was in that range.  If we
treated pointer comparisons as always signed then such tests won't work
in the expected manner.  Of course ANSI might have something to say
about the signedness of pointers, I don't know offhand.


  > We could, in theory, allow that optimization if we knew that the
  > things compared were pointers (that's where we can make conservative
  > use of REGNO_POINTER_FLAG; if it's on then it's a pointer) and that
  > the subsequent test of cc0 is unsigned.  I'm sorry I didn't say that
  > more clearly.
Ah.  Yes.  And I've managed to eliminate most (if not all) cases where
REGNO_POINTER_FLAG is set, but the value is not a pure pointer (does not
point into the object, but rather to an address before or after the
object).

jeff



More information about the Gcc-patches mailing list