This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] More aliasing fixes
- From: law at redhat dot com
- To: Jan Hubicka <jh at suse dot cz>
- Cc: Diego Novillo <dnovillo at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 05 Jan 2004 22:49:30 -0700
- Subject: Re: [tree-ssa] More aliasing fixes
- Reply-to: law at redhat dot com
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
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.