This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Java inliner
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Andrew Haley <aph at cambridge dot redhat dot com>
- Cc: Mark Mitchell <mark at codesourcery dot com>,Per Bothner <per at bothner dot com>, Fergus Henderson <fjh at cs dot mu dot OZ dot AU>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>,"java at gcc dot gnu dot org" <java at gcc dot gnu dot org>
- Date: Wed, 12 Jun 2002 12:18:43 -0400 (EDT)
- Subject: Re: RFC: Java inliner
On Wed, 12 Jun 2002, Daniel Berlin wrote:
> On Wed, 12 Jun 2002, Andrew Haley wrote:
>
> > Mark Mitchell writes:
> > >
> > >
> > > > I believe the right thing to do in the short term is extend the C/C++
> > > > inliner to understand the Java trees. Almost all of the tree codes
> > > > encountered will be generic tree codes defined in tree.def.
> > >
> > > If that is true -- and if languages other than Java are actually using
> > > these tree codes -- that is fine.
> > >
> > > The current inliner already has mechanisms for language-specific
> > > extensions. If those can be used, or it can be easily extended so that
> > > they can be used, great.
> >
> > Okay.
> >
> > > The contention was that the current inliner could *not* be used, and that
> > > an entirely new one had to be written.
> >
> > Not exactly, although some of the structures used in the inliner
> > (e.g. statement expressions) aren't going to make my life very easy.
>
> It shouldn't be all that difficult to get rid of the statement
> expressions.
>
> In fact, it might be the case that we can just remove the statement
> expression wrapper right now, and it'll still just work.
> i'll check.
By this, i meant doing it the way we are doing simplification of them,
which is to pre-insert the body of the statement expression, store the
return value to a temporary, replace the call_expr with the temporary.
Obviously, you can't just remove the statement expression wrapper
literally.
> >
> > Andrew. > >
> >
>
>
>