[Bug regression/52272] New: [4.7 regression] Performance regresswion of 410.bwaves on x86.

[Bug regression/52272] New: [4.7 regression] Performance regresswion of 410.bwaves on x86.

[vbyakovl23 at gmail dot com]

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

             Bug #: 52272
           Summary: [4.7 regression] Performance regresswion of 410.bwaves
                    on x86.
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: regression
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vbyakovl23@gmail.com


Created attachment 26671
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26671
Reduced testcase

Commit 
2012-02-06  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/50955
        * tree-ssa-loop-ivopts.c (get_computation_cost_at): Artificially
        raise cost of expressions that replace an address with an
        expression based on a different pointer.

causes performance regression on 410.bwaves
    base: -2.33%
    peak: -3.82%
I attached a reduced testcase and dumps of compilers before and after commit.
Command line to reproduce

gfortran -w -g -m32  -static -S t.s -O3 -funroll-loops -msse2 -mfpmath=sse
-ffast-math -march=corei7 t.f

[Bug regression/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.

[vbyakovl23 at gmail dot com]

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

--- Comment #1 from Vladimir Yakovlev <vbyakovl23 at gmail dot com> 2012-02-16 08:16:27 UTC ---
Created attachment 26672
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26672
Good case before commit

[Bug regression/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.

[vbyakovl23 at gmail dot com]

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

--- Comment #2 from Vladimir Yakovlev <vbyakovl23 at gmail dot com> 2012-02-16 08:17:53 UTC ---
Created attachment 26673
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26673
Bad case after commit

[Bug tree-optimization/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
           Keywords|                            |missed-optimization
   Last reconfirmed|                            |2012-02-16
          Component|regression                  |tree-optimization
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1
   Target Milestone|---                         |4.7.0

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-16 10:39:34 UTC ---
I didn't see the regression on a SandyBridge machine with -Ofast -funroll-loops
-fpeel-loops -march=native [-flto].  But I can see the regression on an
AMD Bulldozer machine.

I will have a look.  Note that the patch was to fix a wrong-code issue, so
we may have to live with the performance regression.

[Bug tree-optimization/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rakdver at gcc dot gnu.org

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-16 12:41:30 UTC ---
Proposed patch:

Index: gcc/tree-ssa-loop-ivopts.c
===================================================================
--- gcc/tree-ssa-loop-ivopts.c  (revision 184304)
+++ gcc/tree-ssa-loop-ivopts.c  (working copy)
@@ -2506,6 +2506,15 @@ add_iv_value_candidates (struct ivopts_d
   if (offset
       || base != iv->base)
     add_candidate (data, base, iv->step, false, use);
+
+  /* Fourth, try removing the base-object for pointer IVs.  */
+  if (TREE_CODE (iv->base) == POINTER_PLUS_EXPR)
+    {
+      tree base_object = iv->base_object;
+      STRIP_NOPS (base_object);
+      if (operand_equal_p (TREE_OPERAND (iv->base, 0), base_object, 0))
+       add_candidate (data, TREE_OPERAND (iv->base, 1), iv->step, false, use);
+    }
 }

 /* Adds candidates based on the uses.  */
@@ -4062,7 +4071,13 @@ get_computation_cost_at (struct ivopts_d
       if (use->iv->base_object
          && cand->iv->base_object
          && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
-       return infinite_cost;
+       {
+         if (dump_file && (dump_flags & TDF_DETAILS))
+           fprintf (dump_file, "Not considering candidate %d for use %d "
+                    "because they have different pointer bases%s\n",
+                    cand->id, use->id, address_p ? "(address_p)" : "");
+         return infinite_cost;
+       }
     }

   if (TYPE_PRECISION (utype) < TYPE_PRECISION (ctype))

[Bug tree-optimization/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-16 12:40:06 UTC ---
Before the patch we choose

Improved to:
  cost: 128 (complexity 0)
  cand_cost: 19
  cand_use_cost: 28 (complexity 0)
  candidates: 2, 4, 7
   use:0 --> iv_cand:4, cost=(2,0)
   use:1 --> iv_cand:4, cost=(2,0)
   use:2 --> iv_cand:2, cost=(0,0)
   use:3 --> iv_cand:7, cost=(0,0)
   use:4 --> iv_cand:7, cost=(4,0)
   use:5 --> iv_cand:7, cost=(4,0)
   use:6 --> iv_cand:7, cost=(4,0)
   use:7 --> iv_cand:7, cost=(4,0)
   use:8 --> iv_cand:7, cost=(4,0)
   use:9 --> iv_cand:7, cost=(4,0)

and now we do not consider for example candidate 7 for use 4:

candidate 7
  var_before ivtmp.190
  var_after ivtmp.190
  incremented before exit test
  type character(kind=4)
  base (character(kind=4)) (a_296(D) + (((sizetype) stride.88_9 + (sizetype)
pretmp.141_661) + 1) * 8)
  step 8
  base object (void *) a_296(D)

use 4
  generic
  in statement D.2322_387 = axp_318(D) + D.2321_367;

  at position
  type real(kind=8)[0:D.1963] * restrict
  base axp_318(D) + (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1)
* 8
  step 8
  base object (void *) axp_318(D)
  related candidates

and we really do not want to do that because of the wrong-code issue.
We instead end up with

Improved to:
  cost: 133 (complexity 7)
  cand_cost: 13
  cand_use_cost: 39 (complexity 7)
  candidates: 4, 5
   use:0 --> iv_cand:4, cost=(2,0)
   use:1 --> iv_cand:4, cost=(2,0)
   use:2 --> iv_cand:5, cost=(0,0)
   use:3 --> iv_cand:5, cost=(5,1)
   use:4 --> iv_cand:5, cost=(5,1)
   use:5 --> iv_cand:5, cost=(5,1)
   use:6 --> iv_cand:5, cost=(5,1)
   use:7 --> iv_cand:5, cost=(5,1)
   use:8 --> iv_cand:5, cost=(5,1)
   use:9 --> iv_cand:5, cost=(5,1)

where

candidate 5 (important)
  var_before ivtmp.188 
  var_after ivtmp.188
  incremented before exit test
  type sizetype
  base 0
  step 8

I think what we miss to relate uses 4 to 9 which all are of the form
 base <parameter> + (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1)
* 8
is to have a candidate which has the base object stripped and thus
only tracks
 (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8
which we have as IV at least:
ssa name D.2332_451
  type sizetype
  base (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8
  step 8
and redundant:
ssa name D.2354_680
  type sizetype
  base (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8
  step 8
ssa name D.2343_692
  type sizetype
  base (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8
  step 8
ssa name D.2365_752
  type sizetype
  base (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8
  step 8
ssa name D.2376_763
  type sizetype
  base (((sizetype) stride.88_9 + (sizetype) pretmp.141_661) + 1) * 8
  step 8
but no associated candidate(s).  If we add a candidate for it (9) we
end up with

Improved to:
  cost: 131 (complexity 0)
  cand_cost: 15
  cand_use_cost: 35 (complexity 0)
  candidates: 4, 9
   use:0 --> iv_cand:4, cost=(2,0)
   use:1 --> iv_cand:4, cost=(2,0)
   use:2 --> iv_cand:9, cost=(3,0)
   use:3 --> iv_cand:9, cost=(4,0)
   use:4 --> iv_cand:9, cost=(4,0)
   use:5 --> iv_cand:9, cost=(4,0)
   use:6 --> iv_cand:9, cost=(4,0)
   use:7 --> iv_cand:9, cost=(4,0)
   use:8 --> iv_cand:9, cost=(4,0)
   use:9 --> iv_cand:9, cost=(4,0)

but with that change we now unroll the innermost loop twice, so I'm not
sure it will pay off.  The code generation differences even for the
originally patch that caused the regression are only in scheduling
and register allocation (so -fschedule-insns may recover it, or
-fsched-pressure).

[Bug tree-optimization/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.

[vbyakovl23 at gmail dot com]

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

--- Comment #6 from Vladimir Yakovlev <vbyakovl23 at gmail dot com> 2012-02-16 14:42:36 UTC ---
I've checked. The patch fixes the regression. Thanks.

[Bug tree-optimization/52272] [4.7 regression] Performance regresswion of 410.bwaves on x86.

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-20 12:21:19 UTC ---
Even though it makes sense (I think) the patch regresses more benchmarks
than it fixes, and it does not fix the 410.bwaves regression fully.  Defering
to 4.8 as I don't have any better ideas off my head.

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
   Target Milestone|4.7.0                       |4.8.0
            Summary|[4.7 regression]            |[4.7/4.8 regression]
                   |Performance regresswion of  |Performance regresswion of
                   |410.bwaves on x86.          |410.bwaves on x86.

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[izamyatin at gmail dot com]

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

Igor Zamyatin <izamyatin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |izamyatin at gmail dot com

--- Comment #8 from Igor Zamyatin <izamyatin at gmail dot com> 2012-03-26 11:05:52 UTC ---
Sort of experimental patch

Index: tree-ssa-loop-ivopts.c
===================================================================
--- tree-ssa-loop-ivopts.c      (revision 185039)
+++ tree-ssa-loop-ivopts.c      (working copy)
@@ -4114,6 +4114,7 @@
   else if (ratio == 1)
     {
       tree real_cbase = cbase;
+      int diff_cost, add_cost1;

       /* Check to see if any adjustment is needed.  */
       if (cstepi == 0 && stmt_is_after_inc)
@@ -4133,7 +4134,10 @@
                              ubase, real_cbase,
                              &symbol_present, &var_present, &offset,
                              depends_on);
+      diff_cost = cost.cost;
       cost.cost /= avg_loop_niter (data->current_loop);
+      if (diff_cost > (add_cost1 = add_cost(TYPE_MODE (ctype), data->speed)))
+          cost.cost += add_cost1;
     }
   else if (address_p
           && !POINTER_TYPE_P (ctype)


 It was found during some side investigation regarding ivopts phase work. 
Patch fixes the regression.

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[meissner at gcc dot gnu.org]

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

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |meissner at gcc dot gnu.org

--- Comment #9 from Michael Meissner <meissner at gcc dot gnu.org> 2012-03-27 23:42:17 UTC ---
I get a regression of about 15% on power7 due to this change.

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[izamyatin at gmail dot com]

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

--- Comment #10 from Igor Zamyatin <izamyatin at gmail dot com> 2012-03-29 11:04:27 UTC ---
Is it possible to look at the regressed test-case and gcc dumps with
-fdump-tree-ivopts-details option w/o that change? 
Thanks in advance

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[izamyatin at gmail dot com]

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

--- Comment #11 from Igor Zamyatin <izamyatin at gmail dot com> 2012-04-19 13:09:25 UTC ---
Another version of the experimental patch is here -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52868

It fixes bwaves regression on x86 and might not trigger performance on other
platforms

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[meissner at gcc dot gnu.org]

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

--- Comment #12 from Michael Meissner <meissner at gcc dot gnu.org> 2012-04-20 23:15:56 UTC ---
Created attachment 27205
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27205
ivtops dump from subversion id 183933 (before regression)

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[meissner at gcc dot gnu.org]

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

--- Comment #13 from Michael Meissner <meissner at gcc dot gnu.org> 2012-04-20 23:16:24 UTC ---
I'm attaching the ivopts dump from 4 runs:
1) Subversion id 183933, the revision before the change;
2) Subversion id 183934, the revision that slowed down bwaves;
3) Subversion id 186630, top of the tree this morning;
4) Subversion id 186630 + the experimental patch.

The experimental patch does not change the code at all on the PowerPC.

1) The mat_times_vec_ function is 27% slower in subversion id 183934;
2) The mat_times_vec_ function is 24% slower in today's versions.

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[meissner at gcc dot gnu.org]

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

--- Comment #14 from Michael Meissner <meissner at gcc dot gnu.org> 2012-04-20 23:19:52 UTC ---
Created attachment 27207
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27207
ivtops dump from subversion id 183934 (after regression)

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[meissner at gcc dot gnu.org]

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

--- Comment #15 from Michael Meissner <meissner at gcc dot gnu.org> 2012-04-20 23:21:14 UTC ---
Created attachment 27208
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27208
ivtops dump from subversion id 186630 (top of tree on April 20th, 2012)

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[meissner at gcc dot gnu.org]

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

--- Comment #16 from Michael Meissner <meissner at gcc dot gnu.org> 2012-04-20 23:22:54 UTC ---
Created attachment 27209
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27209
ivtops dump from subversion id 186630 + experimental patch from Igor Zamyatin

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regression of 410.bwaves on x86.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regression of 410.bwaves on x86.

[aldyh at gcc dot gnu.org]

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

--- Comment #17 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2013-02-09 19:15:15 UTC ---
*** Bug 52868 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/52272] [4.7/4.8/4.9 regression] Performance regression of 410.bwaves on x86.

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.0                       |4.8.1

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-22 14:44:30 UTC ---
GCC 4.8.0 is being released, adjusting target milestone.

[Bug tree-optimization/52272] [4.7/4.8/4.9 regression] Performance regression of 410.bwaves on x86.

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.1                       |4.8.2

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

[Bug tree-optimization/52272] [4.7/4.8/4.9 regression] Performance regression of 410.bwaves on x86.

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.2                       |4.8.3

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

[Bug tree-optimization/52272] [4.7/4.8/4.9 regression] Performance regression of 410.bwaves on x86.

[amker.cheng at gmail dot com]

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

bin.cheng <amker.cheng at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amker.cheng at gmail dot com

--- Comment #21 from bin.cheng <amker.cheng at gmail dot com> ---
Hi Richard,
I looked into PR50955 for which the mentioned commit causing this PR is
applied:

Commit 
2012-02-06  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/50955
        * tree-ssa-loop-ivopts.c (get_computation_cost_at): Artificially
        raise cost of expressions that replace an address with an
        expression based on a different pointer.

I noticed that the offending non-linear use in PR50955 is actually from memory
reference.  If I understand the issue correct, the whole alias issue is
introduced by rewriting iv use with one base_object through candidate with
another incompatible base_object, and it is related to memory reference.  An
genuine non-linear iv use (the pointer never de-referenced, like in this PR)
won't have this issue.

So I come up this idea to relax the condition:

-  if (address_p)
+  if (address_p
+      || (use->iv->base_object
+         && cand->iv->base_object
+         && POINTER_TYPE_P (TREE_TYPE (use->iv->base_object))
+         && POINTER_TYPE_P (TREE_TYPE (cand->iv->base_object))))
     {
       /* Do not try to express address of an object with computation based
         on address of a different object.  This may cause problems in rtl

to non-linear uses which truly occurred in memory reference, something like:

-  if (address_p)
+  if (address_p
+      || (use->in_mem_ref_p
+         && use->iv->base_object
+         && cand->iv->base_object
+         && POINTER_TYPE_P (TREE_TYPE (use->iv->base_object))
+         && POINTER_TYPE_P (TREE_TYPE (cand->iv->base_object))))
     {
       /* Do not try to express address of an object with computation based
         on address of a different object.  This may cause problems in rtl

The flag in_mem_ref_p can be set for appropriate uses when finding interesting
address uses.

With this change, this PR should be resolved while not violating PR50955.

I am not very much into 50955, so how does this sound? I can send a patch for
review if the idea is in right direction.

BTW, I cannot reproduce 50955 with the reported revision of GCC.  The store
isn't deleted by pass_cd_dce, though it is re-written just as the PR reported. 
So maybe I just misunderstood something.

Any words?

Thanks,
bin

[Bug tree-optimization/52272] [4.7/4.8/4.9/4.10 regression] Performance regression of 410.bwaves on x86.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.3                       |4.8.4

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 4.8.3 is being released, adjusting target milestone.

[Bug tree-optimization/52272] [4.8/4.9/5 regression] Performance regression of 410.bwaves on x86.

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

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

[Bug tree-optimization/52272] [4.8/4.9/5/6 regression] Performance regression of 410.bwaves on x86.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

[Bug tree-optimization/52272] [4.9/5/6 regression] Performance regression of 410.bwaves on x86.

[jakub at gcc dot gnu.org]

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

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

[Bug tree-optimization/52272] [4.9/5/6 regression] Performance regression of 410.bwaves on x86.

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug tree-optimization/52272] [4.9/5/6 regression] Performance regression of 410.bwaves on x86.

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amker at gcc dot gnu.org

--- Comment #27 from amker at gcc dot gnu.org ---
I proposed a new approach fixing PR50955.  In that way, we won't have this
regression anymore.
In this comment I want to compare that proposal to the one given by Richard in
comment #5.

Conclusion is, I think that proposal doesn't bring any more obvious benefit
comparing to this one.  Yet this one can handle case with many address type
iv_uses which share common sub-expression except for base_object.

Of course this patch has its own disadvantages.  For example, it needs to add
more candidates.  And since we don't do analysis when adding candidate (that's
in candidate selection), we actually need to add candidates that might be
useful.

We need to analysis iv_uses to add candidates only when necessary as much as
possible.  We also need to handle complexity issue caused by more candidates.