On Wed, 2006-03-08 at 15:05 -0500, Andrew Pinski wrote: > I notice in your PDF, you have: > Since alias analysis results are often conservative, may-alias sets my > contain tens > and enve hundreds of symbols. > > Is there a reason why not tune the aliasing anaysis to return more liberal > results > instead of changing the representation?
Because you can't. > > From looking at Tramp3D, I found (and filed) a case where the aliasing anaysis > was too conservative. The analysis you ask for is, in general, impossible. Even if we went the ridiculous route of trying to special case every single situation where we knew we could remove some single thing from an alias set, they would still be too conservative in some places. > Also that was the only case I could find and it would > reduce the VOPs for this testcase after fixing this issue. I filed this as > PR 26609. Removing the vops in this testcase is possible, but a bit tricky, and somewhat irrelevant. > I can look at the other testcases you mention and find more cases where > aliasing analysis is very conservative and file the bugs for them. This > seems like a better plan than just changing the representation to work > around the fact the may-alias sets are big. may-alias sets may be big, this is a fact of life. As we get into interprocedural and whole-program analysis, they are going to get bigger, not smaller. Designing a representation that can represent large may-alias sets well is 1. A very good idea 2. Completely orthogonal to improving aliasing set precision. Claiming that we will never need this representation because we can always just increase alias precision is not a good argument to make, because it is provably false.
