This is the mail archive of the
mailing list for the GCC project.
Re: stepanov on sparc; sparc backend scheduling issues
- To: dan at cgsoftware dot com (Daniel Berlin)
- Subject: Re: stepanov on sparc; sparc backend scheduling issues
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Tue, 29 May 2001 10:02:13 -0700 (PDT)
- Cc: jbuck at racerx dot synopsys dot com (Joe Buck), dje at watson dot ibm dot com (David Edelsohn), jbuck at synopsys dot COM (Joe Buck), mark at codesourcery dot com (Mark Mitchell), jfm2 at club-internet dot fr, gcc at gcc dot gnu dot org
> > Jason Merrill's ADDRESSOF optimization is supposed to take care of this;
> > the question is why it is not working. That is, why on the PowerPC and
> > x86 do we get loops that needlessly commit the iterator to memory.
> Am I correct in thinking ADDRESSOF == Scalar replacement of aggregates?
Not really, or rather, it's a special case of it. The purpose is to defer
committing an object to memory, even though its address has been taken.
The reason is that, especially with inline functions, many & operators
are cancelled by a matching unary * or ->only_member (where only_member
is the only data member of the object), and if all are cancelled, we can
leave the object in a register even though its address is taken.
It only works for the case of a struct or class that has only one member,
where that member is of a type that can go in a register. However, such
cases are very common in C++ (most STL iterators qualify).
It can be argued that because of the way ADDRESSOF works, the Stepanov
test makes GCC 2.95.x look better than it deserves to look. Some generic
programming libraries, such as the Generic Graph Component Library
( http://www.lsc.nd.edu/research/ggcl/ ), use iterator objects or other
arguments that have multiple fields, and GCC sucks compared to, say,
KAI's compiler on this library. GGCL will be a good test for whenever
we do decide to do scalar replacement of aggregates.
(GGCL is now part of Boost).