[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (or is it because gimplifier considered part of expand)

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (or is it because gimplifier considered part of expand)

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] New: [4.0 Regression] Expand is considered slower? (or is it because gimplifier considered part of expand)

[pinskia at gcc dot gnu dot org]

3.3 can do this in 4.39s while 4.0.0 needs 14.60s.

#define ELSEIF1 else if (!a) f();
#define ELSEIF2     ELSEIF1     else if (a) ;
#define ELSEIF4     ELSEIF2     ELSEIF2
#define ELSEIF8     ELSEIF4     ELSEIF4
#define ELSEIF16    ELSEIF8     ELSEIF8
#define ELSEIF32    ELSEIF16    ELSEIF16
#define ELSEIF64    ELSEIF32    ELSEIF32
#define ELSEIF128   ELSEIF64    ELSEIF64
#define ELSEIF256   ELSEIF128   ELSEIF128
#define ELSEIF512   ELSEIF256   ELSEIF256
#define ELSEIF1024  ELSEIF512   ELSEIF512
#define ELSEIF2048  ELSEIF1024  ELSEIF1024
#define ELSEIF4096  ELSEIF2048  ELSEIF2048
#define ELSEIF8192  ELSEIF4096  ELSEIF4096
#define ELSEIF16384 ELSEIF8192  ELSEIF8192
#define ELSEIF32768 ELSEIF16384 ELSEIF16384
#define ELSEIF65536 ELSEIF32768 ELSEIF32768

void
foo (int a)
{
  int b;

  if (a);
  ELSEIF4096
}

-- 
           Summary: [4.0 Regression] Expand is considered slower? (or is it
                    because gimplifier considered part of expand)
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Keywords: compile-time-hog
          Severity: normal
          Priority: P2
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (or is it because gimplifier considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-13 04:02 -------
4.0.0:
Execution times (seconds)
 preprocessing         :   0.06 ( 0%) usr   0.12 (17%) sys   0.16 ( 1%) wall
 lexical analysis      :   0.12 ( 1%) usr   0.23 (32%) sys   0.47 ( 3%) wall
 parser                :   0.14 ( 1%) usr   0.15 (21%) sys   0.23 ( 1%) wall
 tree gimplify         :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall
 tree eh               :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall
 tree CFG construction :   0.04 ( 0%) usr   0.01 ( 1%) sys   0.06 ( 0%) wall
 tree CFG cleanup      :   0.09 ( 1%) usr   0.00 ( 0%) sys   0.10 ( 1%) wall
 tree PTA              :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
 tree PHI insertion    :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
 tree SSA rewrite      :   0.02 ( 0%) usr   0.01 ( 1%) sys   0.03 ( 0%) wall
 tree SSA other        :   0.06 ( 0%) usr   0.07 (10%) sys   0.16 ( 1%) wall
 tree operand scan     :   0.04 ( 0%) usr   0.07 (10%) sys   0.10 ( 1%) wall
 dominator optimization:   0.08 ( 1%) usr   0.00 ( 0%) sys   0.08 ( 1%) wall
 tree conservative DCE :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
 tree rename SSA copies:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 dominance frontiers   :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
 expand                :  13.82 (95%) usr   0.04 ( 6%) sys  14.35 (90%) wall
 global alloc          :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 symout                :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall
 TOTAL                 :  14.60             0.71            15.95


3.3:

Execution times (seconds)
 cfg construction      :   0.09 ( 2%) usr   0.01 ( 2%) sys   0.00 ( 0%) wall
 cfg cleanup           :   3.47 (79%) usr   0.00 ( 0%) sys   2.00 (50%) wall
 trivially dead code   :   0.07 ( 2%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 preprocessing         :   0.04 ( 1%) usr   0.12 (22%) sys   0.00 ( 0%) wall
 lexical analysis      :   0.17 ( 4%) usr   0.19 (35%) sys   0.00 ( 0%) wall
 parser                :   0.08 ( 2%) usr   0.16 (29%) sys   0.00 ( 0%) wall
 expand                :   0.04 ( 1%) usr   0.01 ( 2%) sys   0.00 ( 0%) wall
 integration           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 jump                  :   0.08 ( 2%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 CSE                   :   0.15 ( 3%) usr   0.03 ( 5%) sys   0.00 ( 0%) wall
 branch prediction     :   0.11 ( 3%) usr   0.01 ( 2%) sys   2.00 (50%) wall
 local alloc           :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 global alloc          :   0.00 ( 0%) usr   0.01 ( 2%) sys   0.00 ( 0%) wall
 flow 2                :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 rest of compilation   :   0.05 ( 1%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall
 TOTAL                 :   4.39             0.55             4.00


remove_useless_stmts is counted in expand.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.0 Regression] Expand is  |[4.0 Regression] Expand is
                   |considered slower? (or is it|considered slower?
                   |because gimplifier          |(remove_useless_stmts is
                   |considered part of expand)  |considered part of expand)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-13 20:26 -------
Someone should see if remove_useless_stmts is really help on compile time or not, this case shows that 
it is not a help at all, maybe it should be done after CFG is done.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-13 20:33 -------
there is a cfg version of remove_useless_stmts, cfg_remove_useless_stmts, maybe someone (not me) 
can do some timings (code gen) on this patch:
Index: tree-cfg.c
===============================================================
====
RCS file: /cvs/gcc/gcc/gcc/tree-cfg.c,v
retrieving revision 2.74
diff -u -p -r2.74 tree-cfg.c
--- tree-cfg.c	10 Oct 2004 13:16:35 -0000	2.74
+++ tree-cfg.c	13 Oct 2004 20:32:51 -0000
@@ -1635,7 +1635,7 @@ struct tree_opt_pass pass_remove_useless
 {
   "useless",				/* name */
   NULL,					/* gate */
-  remove_useless_stmts,			/* execute */
+  cfg_remove_useless_stmts,			/* execute */
   NULL,					/* sub */
   NULL,					/* next */
   0,					/* static_pass_number */


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-14 14:07 -------
Unless someone can prove that eh part of remove_useless_stmt does not matter any more because of 
the lowering of eh, I think the patch is wrong.  Maybe we can move the eh part into the lowering of the 
eh and then we don't have to worry about that if we don't do it alreay.

Doing CFG already does the some parts of remove_useless_stmt and cfg_remove_useless_stmt does the 
conditional part already. I think eh lowering does the rest so maybe we can remove this compile time 
problem.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-10-14 14:07:16
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-14 14:55 -------
Well I just provided to my self that lowering eh actually does the same job as the old 
remove_useless_stmts.  I will submit a patch after class and getting home to remove 
remove_useless_stmts and change it to cfg_ remove_useless_stmts.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-14 18:38 -------
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01202.html>.  I was convenced by RTH 
that removing r_u_s actually can slow it down but he also helped me to figure out where the problem is.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-14 21:59 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-14 22:00 -------
Subject: Bug 17967

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	pinskia@gcc.gnu.org	2004-10-14 22:00:07

Modified files:
	gcc            : ChangeLog tree-cfg.c 

Log message:
	2004-10-14  Andrew Pinski  <pinskia@physics.uc.edu>
	
	PR middle-end/17967
	Revert:
	* tree-cfg.c (remove_usless_stmts_cond):  Fold statement.
	(remove_useless_stmts_1):  Fold trees we know how to fold.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5885&r2=2.5886
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.75&r2=2.76



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-15 04:16 -------
Subject: Bug 17967

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	pinskia@gcc.gnu.org	2004-10-15 04:15:52

Modified files:
	gcc            : ChangeLog tree-cfg.c 

Log message:
	2004-10-14  Andrew Pinski  <pinskia@physics.uc.edu>
	
	Revert:
	2004-10-14  Andrew Pinski  <pinskia@physics.uc.edu>
	PR middle-end/17967
	Revert:
	* tree-cfg.c (remove_usless_stmts_cond):  Fold statement.
	(remove_useless_stmts_1):  Fold trees we know how to fold.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5895&r2=2.5896
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.76&r2=2.77



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-15 04:17 -------
The patch had to be reverted as it caused some missed-optimization regressions.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-17 22:55 -------
As said before this patch fixes this regression but cause some optimizations regression because fold 
does not fold &a[0] + 1 into &a[1] but only fold_stmt (I might be able to remove the fold_stmt on the 
COND_EXPR).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED
           Keywords|patch                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 18:31 -------
I am testing a new patch which this time I fully tested it (it only removes the fold_stmt from the 
COND_EXPR as that is not needed at all).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-23 19:16 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-23 19:17 -------
Subject: Bug 17967

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	pinskia@gcc.gnu.org	2004-10-23 19:17:09

Modified files:
	gcc            : ChangeLog tree-cfg.c 

Log message:
	2004-10-23  Andrew Pinski  <pinskia@physics.uc.edu>
	
	PR middle-end/17967
	* tree-cfg.c (remove_usless_stmts_cond):  Don't Fold statement.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5996&r2=2.5997
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.88&r2=2.89



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17967