This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] alias analysis
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: 18 Feb 2003 19:10:06 -0500
- Subject: Re: [tree-ssa] alias analysis
- References: <200302150012.h1F0CKXT005949@localhost.redhat.com>
On Fri, 2003-02-14 at 19:12, law@redhat.com wrote:
> >Faster than what we have now? At this point I will need to see the
> >patch :) Right now we are so fast mainly because we bag most
> >addressables and dereferences together.
> Yup. My scheme is faster than what we have now.
>
Faster to compute aliasing, or faster when combined with the SSA
builder? If you are trying to improve times that are in the fractions
of a second for a multi-second compile, I think you're wasting your
time. We have much bigger performance problems in the branch, don't you
think?
> FWIW, after my various improvements to CCP, alias analysis has become the
> clear CPU hog again as far as the tree optimizers are concerned
> (with gimplification running a close second). And I know how to make
> mine even faster and probably use less memory as well :-)
>
Now you lost me again. Why are you so interested in making alias
analysis a CPU hog? We were trying to do the opposite!
> >What I would like to avoid is getting into the situation where we start
> >to implement various additional heuristics to the type-based analyzer
> >instead of relying on the PTA code. I think I'd rather have a good PTA
> >implementation. The type-based analyzer was something to get by in the
> >meantime, really.
> Conceptually you should think of PTA as a way to prune the aliases
> found by type analysis. In all likelihood they're going to have to
> work together.
>
I always thought that TBA was a way of pruning PTA. You first do a
quick TBA query, if that fails, you do PTA.
Diego.