Re: type based aliasing again

[Jeffrey A Law <law@cygnus.com>]

  In message < 19990908234259.A23715@cygnus.com >you write:
  > On Wed, Sep 08, 1999 at 11:45:17PM -0700, Mark Mitchell wrote:
  > >   We'll enter (mem:SI (reg:SI 100) 1) in the gcse expression tables,
  > >   we'll see that (mem:SI (reg:SI 100) 2) matches it, and reuse the
  > >   same expression number. 
  > > 
  > > I don't know this code at all, but shouldn't we not think these match?
  > 
  > It's been a week or two since I poked at this -- at the time
  > there was some line of reasoning that led me to believe that
  > that would simply cause a different sort of failure.
  > 
  > Jeff, do you remember?
It's real fuzzy now.  I thought we were looking at the stack slot reuse
code as the culprit.

But given the way we do alias analysis we have two mems with different alias,
thus they're assumed not to alias.

I wasn't aware that we were putting the two memory references into the same
slot in the expression table.  That's interesting and would cause problems.
It seems to me that two memory references with different alias sets need to
be two different expressions.

The question then becomes what happens when we try to hoist these two
expressions.  In particular can we ever hoist them into the same block.

I'm 99% certain the answer is no if we can split critical edges.  The
answer is yes if we can not split critical edges.

Also note, gcse would currently do nothing with that case since you're
talking about assignment motion, not expression motion.  ie, we currently
move expression evaluations.  Not assignments.

Assignment motion is in the long term plans, particularly once we have the new
gcse code from Andrew.  Conceptually it's a simple extension to our existing
expression motion and involves moving assignments upwards in the cfg) to expose
more redundancies.

Also note that given the downward store motion support Andrew is doing, plus
assignment motion support, then we can do partial dead code elimination
(which involves moving assignments down in the cfg to expose code which is
dead, but only on certain paths through the cfg).

jeff