Re: libg++ won't build with latest snapshots

[Alexandre Oliva <oliva at lsd dot ic dot unicamp dot br>]

On Jan  5, 2000, Mark Mitchell <mark@codesourcery.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <oliva@lsd.ic.unicamp.br> writes:
>>> + /* Don't use tree-inlining for functions with named return
>>> values.  + That doesn't work properly because we don't do any
>>> translation of + the RETURN_INITs when they are copied.  */ +
>>> DECL_UNINLINABLE (current_function_decl) = 1;

Alexandre> Is this supposed to remain so, or will there be some
Alexandre> effort to arrange that functions with named return
Alexandre> values become inlinable?  

> They're still RTL inlinable -- nothing has been lost relative to the
> good old days.

Ah!  Good.

Alexandre> uninlinable, I'll post a patch to the docs to state
Alexandre> this.  Maybe we should even deprecate named return
Alexandre> values, now that we have inlining of trees, which I
Alexandre> believe accomplishes a similar degree of optimization.

> 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.  Unless the
copy-constructor and the destructor are inlinable and trivial, but
then, the optimization would probably have occurred in RTL level too.
Maybe not in all cases, though, due to addressof issues.  But maybe
I'm talking nonsense :-)

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them