RFD: RTX_UNCHANGING_P and other ways to optimize memrefs

[Bernd Schmidt <bernds at cambridge dot redhat dot com>]

It seems like lately we have been running into lots of problems with the
RTX_UNCHANGING_P bit; people get confused about what it means, and some
transformations subtly break if the involved rtl is marked unchanging.
The root cause of the problems seems to be that unchanging MEMs can be
written to.
It has also been questioned whether it buys us anything at all.  (I'm
assuming RTX_UNCHANGING_P is mostly interesting for MEMs, and not for
REGs).

Do we know/believe that keeping RTX_UNCHANGING_P in its present form is
a win that enables important optimizations?  If not, removing it could
reduce the number of problems that show up, and we may be able to reuse
the bit for something more interesting.

There are a couple of other interesting properties of a MEM that could
be tracked and would help optimizations.  I'm mainly concerned about ia64
at the moment, so here's a list of problems on that platform:

1. We really want to know which memory references cannot possibly trap.
   If we know this, the scheduler can move them across basic block
   boundaries.  Once we implement control speculation, knowing that a
   particular load can't trap will help us prevent generating unnecessary
   checking code.
   Nontrapping memory references I'm aware of are loads from the pic offset
   table, accesses to non-weak global variables, stack accesses, loads from
   the constant pool or from case vectors.
2. It would help if there was a way to have a mapping from a MEM rtx to
   an offset in the stack frame (obviously only for stack slots).  The
   lack of decent addressing modes on ia64 means that we often don't get
   very good information out of the alias analysis - addresses are always
   plain regs, and after reload hard regs get reused too often to be able
   to tell what they contain.
   I don't see a good way to do this without adding another field to all
   MEMs (and hence, all REGs), and that is probably unacceptable.
3. In addition to alias sets, it would be nice to know what region of
   memory a given MEM belongs to.  That way we could e.g. determine that
   a load from the constant pool or from the GOT is constant and won't
   conflict with stores (part of what RTX_UNCHANGING_P gives us), or
   we could detect that one MEM references a stack slot and the other a
   global variable and thus can't conflict.

I've implemented #1, reusing the RTX_UNCHANGING_P bit as RTX_NONTRAPPING_P.
The patch also introduced a few new alias sets (for constant pool, GOT and
case vectors), and a way to detect that memory with these alias sets is
constant.  It seems to be a small improvement on ia64 when running spec95.

Comments?


Bernd