Bug 15576 - [4.0 Regression] Class initialization optimization is disabled
Summary: [4.0 Regression] Class initialization optimization is disabled
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: tree-ssa
: P2 normal
Target Milestone: 4.0.0
Assignee: Andrew Pinski
URL:
Keywords: missed-optimization, patch
: 16451 (view as bug list)
Depends on:
Blocks: 8709 12911 17574 18399
  Show dependency treegraph
 
Reported: 2004-05-21 21:03 UTC by Bryce McKinlay
Modified: 2004-11-09 14:36 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 3.4.0
Known to fail: 4.0.0
Last reconfirmed: 2004-10-21 04:30:44


Attachments
patch which I am testing (1.25 KB, patch)
2004-11-05 01:03 UTC, Andrew Pinski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bryce McKinlay 2004-05-21 21:03:13 UTC
gcj used to perform an optimization which eliminated redundant class
initialization calls. For example, given the following example,
_Jv_InitClass(Foo) is called twice from Init.a() when it is only needed once:

class Foo 
{
  static int a;
  static int b;
}

public class Init
{
  int a()
  { 
    return Foo.a + Foo.b;
  }
}

This was done in expr.c build_class_init(), look for
LOCAL_CLASS_INITIALIZATION_FLAG. The optimization was turned off in tree-ssa
branch and needs to be updated to work with the gimplifier.
Comment 1 Andrew Pinski 2004-05-21 21:19:16 UTC
Confirmed, could we make another attribute which says that it only touches the memory passed into 
the function and it is okay to remove if the agruments are the same as it will not do anything else, this 
will also help fortran's "pure" functions too.
Comment 2 Bryce McKinlay 2004-05-21 21:34:53 UTC
Well, _Jv_InitClass isn't really a pure function, as class initialization has
side effects. However after it has been called the first time, all subsequent
calls have no effect.
Comment 3 Andrew Pinski 2004-07-09 16:51:38 UTC
*** Bug 16451 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Pinski 2004-11-05 00:43:37 UTC
I have a fix which just renables the orginal code plus fixes the other part of the front-end.
Comment 5 Andrew Pinski 2004-11-05 01:03:59 UTC
Created attachment 7475 [details]
patch which I am testing
Comment 6 Andrew Pinski 2004-11-05 01:08:05 UTC
I attached the patch which I am testing right now to fix this.
The changelog is:
* check-init.c (check_init): Ignore DECL_EXPR.
* expr.c (always_initialize_class_p): Reenable.
(build_class_init): Use a variable to store the decl.  Also use
boolean_false_node instead of integer_zero_node.
* parse.y (attach_init_test_initialization_flags): Add a decl_expr
to the block.
Comment 7 Andrew Pinski 2004-11-06 03:05:56 UTC
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00400.html>.
Comment 8 CVS Commits 2004-11-09 14:34:03 UTC
Subject: Bug 15576

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	pinskia@gcc.gnu.org	2004-11-09 14:33:36

Modified files:
	gcc/java       : ChangeLog check-init.c expr.c parse.y 

Log message:
	2004-11-09  Andrew Pinski  <pinskia@physics.uc.edu>
	
	PR java/15576
	* check-init.c (check_init): Ignore DECL_EXPR.
	* expr.c (always_initialize_class_p): Reenable.
	(build_class_init): Use a variable to store the decl.  Also use
	boolean_false_node instead of integer_zero_node.
	* parse.y (attach_init_test_initialization_flags): Add a decl_expr
	to the block.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1495&r2=1.1496
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/check-init.c.diff?cvsroot=gcc&r1=1.59&r2=1.60
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/expr.c.diff?cvsroot=gcc&r1=1.209&r2=1.210
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcc&r1=1.519&r2=1.520

Comment 9 Andrew Pinski 2004-11-09 14:36:58 UTC
Fixed, I filed PR 18399 for this optimization not working with the inliner.