[Bug tree-optimization/77839] [6/7 Regression] Memory- and compile time hog at -O1 and above

2016-10-06 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu Oct  6 08:54:37 2016
New Revision: 240829

URL: https://gcc.gnu.org/viewcvs?rev=240829=gcc=rev
Log:
2016-10-06  Richard Biener  

PR tree-optimization/77839
* tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value
lattice transition.

* gcc.dg/torture/pr77839.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77839.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/77839] [6/7 Regression] Memory- and compile time hog at -O1 and above

2016-10-04 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839

--- Comment #4 from Richard Biener  ---
SCC consists of: .MEM_16 .MEM_15 .MEM_35 .MEM_26 ez_12 .MEM_14 wo_37 _5 _6
hy.3_7 _8 .MEM_32 hy.0_1 ez_28 _3 wo_40

Value numbering wo_37 stmt = wo_37 = PHI <0(4), wo_40(5)>
Setting value number of wo_37 to ez_12 (changed)
Value numbering _3 stmt = _3 = ez_28 ^ wo_37;
Applying pattern match.pd:580, gimple-match.c:33849
Match-and-simplified ez_28 ^ wo_37 to 0
RHS ez_28 ^ wo_37 simplified to 0
Setting value number of _3 to 0 (changed)
Value numbering wo_40 stmt = wo_40 = _3;
Setting value number of wo_40 to 0 (changed)

Value numbering wo_37 stmt = wo_37 = PHI <0(4), wo_40(5)>
Setting value number of wo_37 to 0 (changed)
Value numbering _3 stmt = _3 = ez_28 ^ wo_37;
Applying pattern match.pd:83, gimple-match.c:33640
Match-and-simplified ez_28 ^ wo_37 to ez_12
RHS ez_28 ^ wo_37 simplified to ez_12
Setting value number of _3 to ez_12 (changed)
Value numbering wo_40 stmt = wo_40 = _3;
Setting value number of wo_40 to ez_12 (changed)
...


  :
  # tc_11 = PHI <0(4), tc_31(5)>
  # ez_12 = PHI <0(4), ez_28(5)>
  # b8_13 = PHI <0(4), b8_30(5)>
  # wo_37 = PHI <0(4), wo_40(5)>

so we're iterating between "same PHI" and same value.  This is because
only when wo_40 == ez_12 we detect that it is actually zero ... we
fail to apply the wo_40 == 0 -> wo_37 == 0 -> ez_12 == 0 step when we
in the first iteration numbered wo_37 to ez_12.  As the comment says:

  /* First see if it is equivalent to a phi node in this block.  We prefer
 this as it allows IV elimination - see PRs 66502 and 67167.  */

we have the issue that the algorithm doesn't handle all cases, this now
shows we even can oscillate between them :/

[Bug tree-optimization/77839] [6/7 Regression] Memory- and compile time hog at -O1 and above

2016-10-04 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.3

--- Comment #3 from Richard Biener  ---
I'll have a look.

[Bug tree-optimization/77839] [6/7 Regression] Memory- and compile time hog at -O1 and above

2016-10-04 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
There's a cycle in CSSVN:

Value numbering store hy to _6
Setting value number of .MEM_32 to .MEM_32
Value numbering hy.0_1 stmt = hy.0_1 = hy;
Setting value number of hy.0_1 to 0
Value numbering ez_28 stmt = ez_28 = hy.0_1 ^ ez_12;
Applying pattern match.pd:83, gimple-match.c:33234
Match-and-simplified hy.0_1 ^ ez_12 to ez_12
RHS hy.0_1 ^ ez_12 simplified to ez_12
Setting value number of ez_28 to ez_12
Value numbering _3 stmt = _3 = ez_28 ^ wo_37;
Applying pattern match.pd:567, gimple-match.c:33443
Match-and-simplified ez_28 ^ wo_37 to 0
RHS ez_28 ^ wo_37 simplified to 0
Setting value number of _3 to 0 (changed)
Value numbering wo_40 stmt = wo_40 = _3;
Setting value number of wo_40 to 0 (changed)
Starting iteration 46252
Value numbering .MEM_16 stmt = .MEM_16 = PHI <.MEM_18(D)(2), .MEM_35(9)>
Setting value number of .MEM_16 to .MEM_16
Value numbering .MEM_15 stmt = .MEM_15 = PHI <.MEM_16(3), .MEM_32(7)>
Setting value number of .MEM_15 to .MEM_15
Value numbering .MEM_35 stmt = hy ={v} {CLOBBER};
Setting value number of .MEM_35 to .MEM_35
Value numbering .MEM_26 stmt = hy = 0;
RHS 0 simplified to 0
No store match
Value numbering store hy to 0
Setting value number of .MEM_26 to .MEM_26
Value numbering ez_12 stmt = ez_12 = PHI <0(4), ez_28(5)>
Setting value number of ez_12 to ez_12
Value numbering .MEM_14 stmt = .MEM_14 = PHI <.MEM_26(4), .MEM_14(5)>
Setting value number of .MEM_14 to .MEM_26
Value numbering wo_37 stmt = wo_37 = PHI <0(4), wo_40(5)>
Setting value number of wo_37 to 0 (changed)
Value numbering _5 stmt = _5 = b8_13 < wo_37;
Setting value number of _5 to _5
Value numbering _6 stmt = _6 = (int) _5;
Setting value number of _6 to _6
Value numbering hy.3_7 stmt = hy.3_7 = hy;
Setting value number of hy.3_7 to 0
Value numbering _8 stmt = _8 = _6 + hy.3_7;
Applying pattern match.pd:83, gimple-match.c:25537
Match-and-simplified _6 + hy.3_7 to _6
RHS _6 + hy.3_7 simplified to _6
Setting value number of _8 to _6
Value numbering .MEM_32 stmt = hy = _8;
No store match
Value numbering store hy to _6
Setting value number of .MEM_32 to .MEM_32
Value numbering hy.0_1 stmt = hy.0_1 = hy;
Setting value number of hy.0_1 to 0
Value numbering ez_28 stmt = ez_28 = hy.0_1 ^ ez_12;
Applying pattern match.pd:83, gimple-match.c:33234
Match-and-simplified hy.0_1 ^ ez_12 to ez_12
RHS hy.0_1 ^ ez_12 simplified to ez_12
Setting value number of ez_28 to ez_12
Value numbering _3 stmt = _3 = ez_28 ^ wo_37;
Applying pattern match.pd:83, gimple-match.c:33234
Match-and-simplified ez_28 ^ wo_37 to ez_12
RHS ez_28 ^ wo_37 simplified to ez_12
Setting value number of _3 to ez_12 (changed)
Value numbering wo_40 stmt = wo_40 = _3;
Setting value number of wo_40 to ez_12 (changed)
Starting iteration 46253

[Bug tree-optimization/77839] [6/7 Regression] Memory- and compile time hog at -O1 and above

2016-10-04 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-04
 CC||marxin at gcc dot gnu.org
  Known to work||5.4.0
Summary|[7 Regression] Memory- and  |[6/7 Regression] Memory-
   |compile time hog at -O1 and |and compile time hog at -O1
   |above   |and above
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0

--- Comment #1 from Martin Liška  ---
Confirmed, GCC 5.4.0 works fine, starts with GCC 6.1.0.