This is the mail archive of the gcc@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: RFC: Memory SSA. A redesign of the virtual operand scheme.


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.





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