Re: RFC: Disable RTL inlininer for Java?

Re: RFC: Disable RTL inlininer for Java?

[Robert Dewar]

<<Another relevant question is how much do languages such as
g77 and GNAT really benefit from inlining?
>>

Inlining is enormously important in Ada. Actually more important than other
languages because it is a standard and routinely used part of the language
to mark subprograms that can be inlined.

Re: RFC: Disable RTL inlininer for Java?

[Tom Tromey]

>>>>> "Jan" == Jan Hubicka <jh@suse.cz> writes:

Jan> We want to do optimizations at tree level and thus all langauges must
Jan> use trees in order to be fully optimized.

Jan> I believe that getting Java function-at-time should be current
Jan> goal of the Java developers (if time allows, of course)

The .java reader already does this (in fact, I think it was the first
front end to do it).  However, this is less useful than you might
think since the existing tree optimization code is C-specific.

The .class reader doesn't build functions as trees.  I have an 80%
patch to do this, but I lack the time to finish and debug it :-(

Tom

Re: RFC: Disable RTL inlininer for Java?

[Robert Dewar]

We do have front end inlining in GNAT, so we are not completely dependent
on the rtl inliner, though it does catch some cases we miss.

Re: RFC: Disable RTL inlininer for Java?

[Robert Dewar]

<Moving to trees is something the GNAT and g77 folks are going to need
to consider for reasons far from the scope of inlining.  For example,
when GCC is able to optimize data access patterns, such an
optimization will undoubtedly be done using trees.  We might also do
other optimizations at the tree level.
>>

The GNAT folks certainly intend to make this change in the future for
all these good reasons :-)

Re: RFC: Disable RTL inlininer for Java?

[Toon Moene]

Richard Henderson wrote:

> On Thu, May 30, 2002 at 03:06:55AM -0700, David S. Miller wrote:
> > Why don't we just kill the whole RTL inliner on the mainline?

> That would negatively impact Fortran statement functions
> (or whatever they're called) that are currently implemented
> with nested inline functions.

Where *currently* means: as implemented by g77.  If you happen to be a
proponent of removing the RTL inliner, you might want to support
completing g95 - i.e., have it coupled to the tree structure
infrastructure :-)

Thanks in advance.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: RFC: Disable RTL inlininer for Java?

[Geoff Keating]

"David S. Miller" <davem@redhat.com> writes:

>    From: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
>    Date: Thu, 30 May 2002 18:36:45 +1200
> 
>    The RTL inliner seems to be the cause of several crashes and 
>    miscompilations of Java code. In the past I've noticed a few EH-related 
>    gcj crashes that went away with -fno-inline, but more disturbing is PR6820:
>    
>    http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6820
>    
>    The evaluation order for the arguments is apparantly disregarded when 
>    the call is inlined.
>    
>    In addition, the inliner has never really worked very well anyway - only 
>    private/final/static methods that preceded the call in a class got 
>    inlined, and methods from other classes never get inlined, afaik.
>    
> Why don't we just kill the whole RTL inliner on the mainline?
> It rots more and more over time, hey this might provide more
> of an impetus for folks to work on tree inlining for the lagging
> languages :-)

I think killing it completely might be premature, but we could declare
the RTL inliner to be officially obsolete and place front-ends on
notice that they need to move to the tree inliner.  For Ada, I believe
there is a plan to do it.  For g77, it may be possible to make the one
case that's really useful, statement expressions, be done as trees or
inlined by the frontend, and if not we can hope to replace it with
g95.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: RFC: Disable RTL inlininer for Java?

[Richard Henderson]

On Thu, May 30, 2002 at 03:06:55AM -0700, David S. Miller wrote:
> Why don't we just kill the whole RTL inliner on the mainline?

That would negatively impact Fortran statement functions
(or whatever they're called) that are currently implemented
with nested inline functions.



r~

Re: RFC: Disable RTL inlininer for Java?

[Jeff Sturm]

On Thu, 30 May 2002, Bryce McKinlay wrote:
> In addition, the inliner has never really worked very well anyway - only 
> private/final/static methods that preceded the call in a class got 
> inlined, and methods from other classes never get inlined, afaik.

Actually when compiling multiple source files at once gcj can inline
reasonably well, but only if you let the integrator choose.  I've argued
before that automatically inlining every private/final/static method is
the wrong thing to do:

http://gcc.gnu.org/ml/java/2001-07/msg00279.html

For my local builds I've always disabled the Java inliner.

> It is unlikely that any bugs in the old inliner will be fixed since it 
> is no longer used by C and C++. So, I propose to disable inlining in GCJ 
> until we make it use the tree inliner.

Sounds good to me.

Jeff

Re: RFC: Disable RTL inlininer for Java?

[Fergus Henderson]

On 30-May-2002, David S. Miller <davem@redhat.com> wrote:
>    From: Steven Bosscher <s.bosscher@student.tudelft.nl>
>    Date: 30 May 2002 12:59:48 +0200
>    
>    It would be a huge job to have GNAT and g77 use the tree inliner
>    because they don't build functions as trees.

It would also require some work for the Mercury front-end.

Currently the Mercury front-end doesn't use function-at-a-time
compilation, because there is no language-independent tree representation
for switch statements.

(However, Mercury doesn't really benefit from the RTL inliner,
since we do our own inlining pass in the Mercury front-end.)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: RFC: Disable RTL inlininer for Java?

[Richard Kenner]

    > Moving to trees is something the GNAT and g77 folks are going to need
    > to consider for reasons far from the scope of inlining.

    Your right about that of course. I just wanted to point out that it
    could be a heckuva job to *rewrite* these front ends to build functions
    at trees. Who's going to do that?

Me, for GNAT.

Re: RFC: Disable RTL inlininer for Java?

[Richard Kenner]

    Moving to trees is something the GNAT and g77 folks are going to need
    to consider for reasons far from the scope of inlining.

Indeed, moving to function-at-a-time for GNAT is something that's on my
list, though I agree it's a lot of work.

Re: RFC: Disable RTL inlininer for Java?

[Steven Bosscher]

Op do 30-05-2002, om 12:50 schreef David S. Miller:
>    From: Steven Bosscher <s.bosscher@student.tudelft.nl>
>    Date: 30 May 2002 12:59:48 +0200
>    
>    It would be a huge job to have GNAT and g77 use the tree inliner
>    because they don't build functions as trees.
>    
>    Also, the tree inliner still depends on stuff from c-*.
> 
> Moving to trees is something the GNAT and g77 folks are going to need
> to consider for reasons far from the scope of inlining.

Your right about that of course. I just wanted to point out that it
could be a heckuva job to *rewrite* these front ends to build functions
at trees. Who's going to do that?

Killing the RTL inliner now seems premature to me at least. I think it's
a good idea for the long term. You could make the RTL inliner deprecated
for, say, 3.3, and kill it for 3.4 and beyond, but for now I think it
should stay. And in a working state, of course.

Actually it may not be that hard to make GNAT build functions as trees,
I don't know GNAT too well. But have you ever looked at g77? And GNU
Pascal doesn't build functions as trees, either. These front ends need
time to adapt. 

Besides, what infrastructure would you suggest these front ends use?
*Everything* at a higher level than RTL is still quite C-family specific
on the mainline. Maybe it's better to wait for the simplified tree
representation (as used on the ast-optimizer branch) to mature, and work
on other infrastructure changes that allow these front ends to use the
tree optimizations (including the tree inliner).

Greetz
Steven

Re: RFC: Disable RTL inlininer for Java?

[Jan Hubicka]

>    From: Jan Hubicka <jh@suse.cz>
>    Date: Thu, 30 May 2002 13:22:07 +0200
>    
>    So the question is whether we want to keep RTL inliner for longer, when
>    we plan to replace it even when it has noticeable maintenance cost, or
>    whether we want to invest the time to function-at-a-timeizing rest of
>    frontends.
>    
> Another relevant question is how much do languages such as
> g77 and GNAT really benefit from inlining?

Ada definitly does.  There is lots of use of inlining hints in the Ada
programs I've seen.
I don't know about g77.  I gues in default programming style it benefits
only from inlining math functions that is different issue.

Honza

Re: RFC: Disable RTL inlininer for Java?

[David S. Miller]

   From: Jan Hubicka <jh@suse.cz>
   Date: Thu, 30 May 2002 13:22:07 +0200
   
   So the question is whether we want to keep RTL inliner for longer, when
   we plan to replace it even when it has noticeable maintenance cost, or
   whether we want to invest the time to function-at-a-timeizing rest of
   frontends.
   
Another relevant question is how much do languages such as
g77 and GNAT really benefit from inlining?

Re: RFC: Disable RTL inlininer for Java?

[Jan Hubicka]

> > I believe that getting Java function-at-time should be current goal of
> > the Java developers (if time allows, of course), but situation seems to
> > be more complex on fortran side, as f77 fronend is, well, mess and f90
> > project does not appear to be avaialble soon.
> 
> There is also quite a bit of work to make GNAT do function-at-a-time, but
> this is certainly an improvement intended for the future.

Yes, forgot to mention that, sorry.
So the question is whether we want to keep RTL inliner for longer, when
we plan to replace it even when it has noticeable maintenance cost, or
whether we want to invest the time to function-at-a-timeizing rest of
frontends.

I am not sure what other frontends are in existence that does matter
(pascal?) but it will be definitly a lot of work.

Honza

Re: RFC: Disable RTL inlininer for Java?

[Robert Dewar]

> I believe that getting Java function-at-time should be current goal of
> the Java developers (if time allows, of course), but situation seems to
> be more complex on fortran side, as f77 fronend is, well, mess and f90
> project does not appear to be avaialble soon.

There is also quite a bit of work to make GNAT do function-at-a-time, but
this is certainly an improvement intended for the future.

Re: RFC: Disable RTL inlininer for Java?

[Steven Bosscher]

Op do 30-05-2002, om 12:06 schreef David S. Miller:
>    
> Why don't we just kill the whole RTL inliner on the mainline?
> It rots more and more over time, hey this might provide more
> of an impetus for folks to work on tree inlining for the lagging
> languages :-)

It would be a huge job to have GNAT and g77 use the tree inliner because
they don't build functions as trees.

Also, the tree inliner still depends on stuff from c-*.

Greetz
Steven



Things from the C family front ends that tree-inline.c uses:

Macros (in c-common.h):
`DECL_ANON_UNION_ELEMS'
`SCOPE_STMT_BLOCK'
`SCOPE_BEGIN_P'
`SCOPE_END_P'
`STMT_IS_FULL_EXPR_P'
`DECL_NUM_STMTS'
`SCOPE_NO_CLEANUPS_P'
`STMT_EXPR_NO_SCOPE'
`STMT_EXPR_STMT'
`STMT_LINENO_FOR_FN_P'
`STMT_LINENO'
`DECL_STMT_DECL'
`GOTO_FAKE_P'

Tree codes (in c-common.def):
`RETURN_STMT'
`GOTO_STMT'
`EXPR_STMT'
`SCOPE_STMT'
`DECL_STMT'
`EXPR_STMT'
`CLEANUP_STMT'
`STMT_EXPR'
`SCOPE_STMT'
`LABEL_STMT'

Functions:
`build_stmt' (in c-semantics.c)
`statement_code_p' (in c-common.c)
`decl_constant_value' (in c-typeck.c)

Re: RFC: Disable RTL inlininer for Java?

[David S. Miller]

   From: Steven Bosscher <s.bosscher@student.tudelft.nl>
   Date: 30 May 2002 12:59:48 +0200
   
   It would be a huge job to have GNAT and g77 use the tree inliner
   because they don't build functions as trees.
   
   Also, the tree inliner still depends on stuff from c-*.

Moving to trees is something the GNAT and g77 folks are going to need
to consider for reasons far from the scope of inlining.  For example,
when GCC is able to optimize data access patterns, such an
optimization will undoubtedly be done using trees.  We might also do
other optimizations at the tree level.

Re: RFC: Disable RTL inlininer for Java?

[Jan Hubicka]

> "David S. Miller" <davem@redhat.com> writes:
> > Why don't we just kill the whole RTL inliner on the mainline?
> > It rots more and more over time, hey this might provide more
> > of an impetus for folks to work on tree inlining for the lagging
> > languages :-)
> 
> This seems to imply that the tree language is the only supported
> interface to the GCC back end.  I.e. no front end should ever bypass
> the tree code to generate RTL directly for the back end.  Is that so?
> 
> Maybe that's obvious to everyone else working with GCC, but I haven't
> seen it stated anywhere.

I believe this is only way for future.
We want to do optimizations at tree level and thus all langauges must
use trees in order to be fully optimized.
I would fully support disabling the rtl inliner even when it cause
temporary performance problems.
I believe that getting Java function-at-time should be current goal of
the Java developers (if time allows, of course), but situation seems to
be more complex on fortran side, as f77 fronend is, well, mess and f90
project does not appear to be avaialble soon.

Honza
> 
> -- 
> Lars Brinkhoff          http://lars.nocrew.org/     Linux, GCC, PDP-10,
> Brinkhoff Consulting    http://www.brinkhoff.se/    HTTP programming

Re: RFC: Disable RTL inlininer for Java?

[David S. Miller]

   From: Lars Brinkhoff <lars.spam@nocrew.org>
   Date: 30 May 2002 12:42:06 +0200
   
   This seems to imply that the tree language is the only supported
   interface to the GCC back end.  I.e. no front end should ever bypass
   the tree code to generate RTL directly for the back end.  Is that so?

If we do want to support that we have to make a commitment
to treat the RTL inliner as a first class citizen along
with the tree inliner.

Re: RFC: Disable RTL inlininer for Java?

[Lars Brinkhoff]

"David S. Miller" <davem@redhat.com> writes:
> Why don't we just kill the whole RTL inliner on the mainline?
> It rots more and more over time, hey this might provide more
> of an impetus for folks to work on tree inlining for the lagging
> languages :-)

This seems to imply that the tree language is the only supported
interface to the GCC back end.  I.e. no front end should ever bypass
the tree code to generate RTL directly for the back end.  Is that so?

Maybe that's obvious to everyone else working with GCC, but I haven't
seen it stated anywhere.

-- 
Lars Brinkhoff          http://lars.nocrew.org/     Linux, GCC, PDP-10,
Brinkhoff Consulting    http://www.brinkhoff.se/    HTTP programming

Re: RFC: Disable RTL inlininer for Java?

[David S. Miller]

   From: Bryce McKinlay <bryce@waitaki.otago.ac.nz>
   Date: Thu, 30 May 2002 18:36:45 +1200

   The RTL inliner seems to be the cause of several crashes and 
   miscompilations of Java code. In the past I've noticed a few EH-related 
   gcj crashes that went away with -fno-inline, but more disturbing is PR6820:
   
   http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6820
   
   The evaluation order for the arguments is apparantly disregarded when 
   the call is inlined.
   
   In addition, the inliner has never really worked very well anyway - only 
   private/final/static methods that preceded the call in a class got 
   inlined, and methods from other classes never get inlined, afaik.
   
Why don't we just kill the whole RTL inliner on the mainline?
It rots more and more over time, hey this might provide more
of an impetus for folks to work on tree inlining for the lagging
languages :-)

RFC: Disable RTL inlininer for Java?

[Bryce McKinlay]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]

The RTL inliner seems to be the cause of several crashes and 
miscompilations of Java code. In the past I've noticed a few EH-related 
gcj crashes that went away with -fno-inline, but more disturbing is PR6820:

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6820

The evaluation order for the arguments is apparantly disregarded when 
the call is inlined.

In addition, the inliner has never really worked very well anyway - only 
private/final/static methods that preceded the call in a class got 
inlined, and methods from other classes never get inlined, afaik.

Turning the inlining off does not significantly affect GCJ's score on 
scimark or jBYTEmark and it makes libgcj.so about 200k smaller. Note 
that this doesn't turn off the inlining of "java builtins" such as 
Math.cos() which is done in java/builtins.

It is unlikely that any bugs in the old inliner will be fixed since it 
is no longer used by C and C++. So, I propose to disable inlining in GCJ 
until we make it use the tree inliner.

Bryce.



[-- Attachment #2: java-disable-inliner.patch --]
[-- Type: text/plain, Size: 557 bytes --]

2002-05-30  Bryce McKinlay  <bryce@waitaki.otago.ac.nz>

	* lang.c (java_init_options): Turn off inlining.

Index: lang.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/lang.c,v
retrieving revision 1.101
diff -u -r1.101 lang.c
--- lang.c	25 Apr 2002 06:24:40 -0000	1.101
+++ lang.c	30 May 2002 06:38:16 -0000
@@ -769,4 +769,8 @@
 
   /* In Java floating point operations never trap.  */
   flag_trapping_math = 0;
+
+  /* Turn off RTL inliner.  */
+  flag_no_inline = 1;
+  flag_inline_functions = 0;
 }