This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] More aliasing fixes


In message <20031218134528.GM8959@kam.mff.cuni.cz>, Jan Hubicka writes:
 >> On Wed, 2003-12-17 at 07:59, Diego Novillo wrote:
 >> 
 >> > With the current implementation we'd generate 14 vops, the new one would
 >> > generate 18 vops.  But we would have to experiment with real code.  I
 >> > can see definite advantages to the new scheme in pointer-heavy code.
 >> > 
 >> Wait.  There's a fatal flaw in this scheme that I didn't realize
 >> yesterday.  You will be relating variables that cannot possibly alias
 >> each other and block VN based optimizations and DCE.  Consider:
 >> 
 >> foo (int i)
 >> {
 >>    int a, b;
 >>    int *p;
 >> 
 >>    p = (i > 50) ? &a : &b;
 >>    a = 50;
 >>    b = 3;
 >>    if (a > 0)
 >>       *p = 5;
 >> }
 >> 
 >> The assignment to 'b' will block DOM from propagating 50 into (a > 0),
 >> because the assignment to b will create a new version of p's MT.
 >
 >But DOM shall not invalidate A's value just because P's MT is writen
 >into. 
DOM does not invalidate objects from its hash tables except as it leaves
blocks to restore the hash tables to their previous state.

DOM works by hashing the operands, including the VUSES and VDEFS (which
includes their version #).  So if if a & b have the same memory tag, then yes,
storing into "b" means we're not going to know that "a" has the value 50
at the IF statement.

We are *far* better off keeping the memory tags for a & b separate.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]