libg++ won't build with latest snapshots

[Mike Stump]

> To: Mark Mitchell <mark@codesourcery.com>
> From: Alexandre Oliva <oliva@lsd.ic.unicamp.br>
> Date: 07 Jan 2000 09:09:59 -0200

> > Actually, the thing that provides equivalent optimization is the
> > return-value optimization.  That's certainly feasible, now that we can
> > operate on trees, but I'm not sure when it will get done.

> For some reason, I was thinking tree inlining would unify the return
> value of inlined function with the returned variable, but, thinking
> some more about it, it really doesn't make much sense to expect it
> to come up as a side effect of tree inlining.

Yes.  There is a well known optimization that is possible that we
don't do (with rtl).  With trees, it will be trivial to do it.  It is
not only possible, but desirable.  Imagine:

template <class T>
T foo(T f) { return f; }

main() {
       int f = foo(foo(foo(1)));
       printf("f is %d\n, f);
}

in C.  When optimized, one notices that what is left is just a call to
printf with a constant.  Not, if we place the int in a class and wrap
it up with all the right constructors and operators, we find that
there is a `penalty' for doing this.  Lots of people call this the
abstraction penalty.  The goal is to make nice C++ as cheap as plain
C, or put another way, to reduce or totally eliminate all the variable
abstraction penalties.

If you already knew all this, pardon me, I just misread your message.  :-)