[Bug tree-optimization/64058] New: Performance degradation after r216304

[Bug tree-optimization/64058] New: Performance degradation after r216304

[izamyatin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

            Bug ID: 64058
           Summary: Performance degradation after r216304
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: izamyatin at gmail dot com
            Target: x86

Created attachment 34101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34101&action=edit
reproducer

Got a performance regression for the codes similar to attached test (well,
rather specific, my simple attempts to reduce it more failed). Regression root
cause is not obviuos at the first glance but noticed that after r216304 we have
l1=u1 placed differently after expand pass. 
Seems for r216303 this assignment was sinked lower and this potentially affects
live ranges and thus performance.

GCC options: -Ofast -flto -m32

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

[izamyatin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

--- Comment #1 from Igor Zamyatin <izamyatin at gmail dot com> ---
Created attachment 34102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34102&action=edit
"good" dump

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

[izamyatin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

--- Comment #2 from Igor Zamyatin <izamyatin at gmail dot com> ---
Created attachment 34103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34103&action=edit
"bad" dump

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[izamyatin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

--- Comment #4 from Igor Zamyatin <izamyatin at gmail dot com> ---
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

[izamyatin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

--- Comment #5 from Igor Zamyatin <izamyatin at gmail dot com> ---
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

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |law at redhat dot com

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |5.2

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 5.1 has been released.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.