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

[Daniel Berlin <dan@cgsoftware.com>]

Joe Buck <jbuck@synopsys.com> writes:

>> 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.

Yes yes, you are correct, i'm just cleaning up the mess something else
makes, in effect.

You (I would, but i'm having fun with new register allocator work,
and callgraph and loop stuff on trees right now. Maybe in a few more
months) should make a go at real scalar replacement of aggregates in
the ast-optimizer branch. 



-- 
"It's a good apartment because they allow pets.  I have a
Shetland pony named Nikkie.  Last summer Nikkie was involved in
a bizarre electrolysis accident.  All her hair was removed
except for her tail.  Now I rent her out to Hare Krishna family
picnics.
"-Steven Wright