[Bug tree-optimization/64058] [5 Regression] Performance degradation after r216304

2017-10-10 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|5.5 |6.0

[Bug tree-optimization/64058] [5 Regression] Performance degradation after r216304

2017-10-10 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #23 from Jakub Jelinek  ---
GCC 5 branch has been closed, should be fixed in GCC 6 and later.

[Bug tree-optimization/64058] [5 Regression] Performance degradation after r216304

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|5.4 |5.5

--- Comment #22 from Richard Biener  ---
GCC 5.4 is being released, adjusting target milestone.

[Bug tree-optimization/64058] [5 Regression] Performance degradation after r216304

2015-03-03 Thread law at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug tree-optimization/64058] [5 Regression] Performance degradation after r216304

2014-12-02 Thread izamyatin at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

--- Comment #5 from Igor Zamyatin  ---
But at the same time difference in "good" and "bad" .optimized dumps seems to
me insignificant (only some postfix numbers of variables).

[Bug tree-optimization/64058] [5 Regression] Performance degradation after r216304

2014-11-26 Thread izamyatin at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

--- Comment #4 from Igor Zamyatin  ---
Partition maps differ

216303:

 Partition 0 (_1 - 1 101 200 252 267 316 348 )
 
 Partition 16 (l1_lsm.7_159 - 106 159 238 253 )

and for 216304:

 Partition 3 (l1_lsm.7_58 - 58 106 238 253 315 316 )
 
 Partition 31 (u1_lsm.6_252 - 101 252 267 314 348 )

And also for 216304 there is 
Coalesce list: (267)u1_lsm.6_252 & (315)l1_lsm.7_58 [map: 70, 4] : Fail due to
conflict

although for 216303 there is 
Coalesce list: (1)_1 & (253)l1_lsm.7_159 [map: 0, 32] : Fail due to conflict

[Bug tree-optimization/64058] [5 Regression] Performance degradation after r216304

2014-11-25 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #3 from Richard Biener  ---
This sounds like a TER effect - the -fdump-rtl-expand-details dump should show
differences in SSA coalescing / TER replacements.

You are talking about

-(note 291 287 289 65 [bb 65] NOTE_INSN_BASIC_BLOCK)
-(jump_insn 289 291 290 65 (set (pc)
+(note 291 287 16 65 [bb 65] NOTE_INSN_BASIC_BLOCK)
+(insn 16 291 289 65 (set (reg:SI 85 [ l1_lsm.7 ])
+(reg:SI 113 [ u1_lsm.6 ])) /nfs/ims/home/izamyati/test_216304.c:72 -1
+ (nil))
+(jump_insn 289 16 290 65 (set (pc)
 (label_ref 288)) /nfs/ims/home/izamyati/test_216304.c:72 -1
  (nil)
  -> 288)

which doesn't appear in the good dump - thus it looks like u1_lsm.6 and
l1_lsm.7 were coalesced there.

Btw, on trunk the testcase is now optimized to trap unconditionally with -flto
or -fwhole-program because the global vars are not initialized.

Can you check on the coalescing theory?

[Bug tree-optimization/64058] [5 Regression] Performance degradation after r216304

2014-11-24 Thread hjl.tools at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-24
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |5.0
Summary|Performance degradation |[5 Regression] Performance
   |after r216304   |degradation after r216304
 Ever confirmed|0   |1