From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: Richard Henderson Cc: Mark Mitchell , gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <3256.936870125@upchuck.cygnus.com> References: <19990908234259.A23715@cygnus.com> X-SW-Source: 1999-09n/msg00350.html Message-ID: <19990930180200.CA6e9rsztGItg4N1y4cbs3JOg1ppZB2bPsZBiG6fsyE@z> 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