Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Joe Buck <jbuck at synopsys dot COM>]

> Joe Buck <jbuck@synopsys.COM> writes:
> 
> >> I'm rather sure, though, that g++ is not generating efficient code for
> >> complicated, nested STL and STL-like structures in the presence of
> >> libstdc++-v3 (iterators are now classes instead of pointers).
> > 
> > But the classes have one member, so we should still be getting equivalent
> > code, provided that we get ADDRESSOF working as well as it did in
> > 2.95.x.
> 
> Not necessarily.
> Alias analysis for classes says they can alias anything (It puts them
> in set 0).
> Alias analysis for pointers doesn't.

I'm very skeptical of this reasoning.

We're typically talking about code where, after inlining, we can see
*exactly* what the pointer or reference refers to, because it gets set
exactly once.

For the case where ADDRESSOF works, the class object should stay in a
register, so there's no question of aliasing with something in memory.
The problem is with making a decision to put an object in memory too
early.

The iterator is a class, yes, but it has only one data member, which is
a pointer.  There shouldn't be any impact on the aliasing analysis.

> This can screw us considerably in these cases, since optimizations on
> memory will see they can alias everything, and not touch them (or
> anything before them, since we have to kill those too).
> 
> The reason i started to come up with a patch in the first place to fix
> this is because it's quite visible with store motion fixed. 

Your store motion work cleans up stuff that, in this case, never should
have been generated in the first place.