[Bug target/65660] New: [5 Regression] 252.eon regression on bdver2 with -Ofast

[Bug target/65660] New: [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

            Bug ID: 65660
           Summary: [5 Regression] 252.eon regression on bdver2 with
                    -Ofast
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
            Target: x86_64-*-*

Created attachment 35211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35211&action=edit
-fopt-info-vec difference

r220580 regressed 252.eon on bdver2 with -Ofast
(http://gcc.opensuse.org/SPEC/CINT/sb-megrez-head-64/252_eon_big.png). 
Actually I didn't verify yet it was r220580 but the regression appeared in the
range 220566:220590.

Attached is the difference in -fopt-info-vec where '-' is r220579 and '+' is
r220580.

As expected we vectorize a lot more but also some basic-block vectorizations
are gone it seems (btw, stupid spec separates stdout and stderr so for .h files
we don't easily see what sources they were included from)

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org
   Target Milestone|---                         |5.0

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Happens apparently also on Intel cpus, see PR65076 comment 37 .

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
http://gcc.opensuse.org/SPEC/CINT/sb-czerny-head-64/252_eon_recent.png

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks like we now vectorize using loop vect instead of basic-block
vectorization.  The overhead might be noticable.  For example

 ./ggSpectrum.h:48:4: note: loop vectorized
-./ggSpectrum.h:49:18: note: basic block vectorized
-./ggSpectrum.h:49:18: note: basic block vectorized
-ggPathDielectricMaterial.cc:36:60: note: basic block vectorized
+./ggSpectrum.h:48:4: note: loop vectorized
+./ggSpectrum.h:48:4: note: loop peeled for vectorization to enhance alignment
+./ggSpectrum.h:48:4: note: loop vectorized
+./ggSpectrum.h:48:4: note: loop peeled for vectorization to enhance alignment
+./ggSpectrum.h:48:4: note: loop vectorized
+./ggSpectrum.h:48:4: note: loop peeled for vectorization to enhance alignment
+./ggSpectrum.h:48:4: note: loop vectorized
+./ggSpectrum.h:48:4: note: loop peeled for vectorization to enhance alignment
+./ggSpectrum.h:48:4: note: loop vectorized
+./ggSpectrum.h:48:4: note: loop peeled for vectorization to enhance alignment

is all from ggPathDielectricMaterial.cc.

Not sure why we peel for alignment at all as bdver2 has
vec_align_load_cost == vec_unalign_load_cost == vec_store_cost (there isn't
any unaligned store cost but IIRC an unalinged store consumes two store buffers
thus aligning the stores might be profitable).

Btw, the loop in question is:

    void Set(float d) {
   for (int i = 0; i < nComponents(); i++)
      data[i] = d;
}

where I can very well imagine that nComponents() is _not_ large enough to
warrant loop vectorization (data is an array of 8 floats).  nComponents()
returns constant 8.

With bdver2 we now have

t.c:4:20: note: vectorization_factor = 4, niters = 8
t.c:4:20: note: === vect_update_slp_costs_according_to_vf ===
cost model: prologue peel iters set to vf/2.
cost model: epilogue peel iters set to vf/2 because peeling for alignment is
unknown.
t.c:4:20: note: Cost model analysis:
  Vector inside of loop cost: 4
  Vector prologue cost: 8
  Vector epilogue cost: 0
  Scalar iteration cost: 4
  Scalar outside cost: 0
  Vector outside cost: 8
  prologue iterations: 2
  epilogue iterations: 2
  Calculated minimum iters for profitability: 2
t.c:4:20: note:   Runtime profitability threshold = 3
t.c:4:20: note:   Static estimate profitability threshold = 3
t.c:4:20: note: epilog loop required

while generic has

t.c:4:20: note: vectorization_factor = 4, niters = 8
t.c:4:20: note: === vect_update_slp_costs_according_to_vf ===
cost model: prologue peel iters set to vf/2.
cost model: epilogue peel iters set to vf/2 because peeling for alignment is
unknown.
t.c:4:20: note: Cost model analysis:
  Vector inside of loop cost: 1
  Vector prologue cost: 11
  Vector epilogue cost: 2
  Scalar iteration cost: 1
  Scalar outside cost: 0
  Vector outside cost: 13
  prologue iterations: 2
  epilogue iterations: 2
  Calculated minimum iters for profitability: 17
t.c:4:20: note:   Runtime profitability threshold = 16
t.c:4:20: note:   Static estimate profitability threshold = 16
t.c:4:20: note: not vectorized: vectorization not profitable.

somehow the prologue cost looks off for bdver2.

Testcase:

struct ggSpectrum {
    void Set (float d)
      {
        for (int i = 0; i < 8; i++)
          data[i] = d;
      }
    float data[8];
};

void foo (ggSpectrum *s, float d)
{
  s->Set(d);
}

now the best course of action is of course to not even consider peeling
this loop for alignment ... (if it can otherwise vectorize).

I think we run into round-off errors with my fix on bdver2, I have a crude
fix for that.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
With a true fix I get

t.c:3:20: note: Cost model analysis:
  Vector inside of loop cost: 4
  Vector prologue cost: 13
  Vector epilogue cost: 11
  Scalar iteration cost: 4
  Scalar outside cost: 0
  Vector outside cost: 24
  prologue iterations: 2
  epilogue iterations: 2
  Calculated minimum iters for profitability: 7
t.c:3:20: note:   Runtime profitability threshold = 6
t.c:3:20: note:   Static estimate profitability threshold = 6

thus we still vectorize the loop for bdver2.  This is because of an oddity
in its cost model which has

  6,                                    /* scalar_stmt_cost.  */
  4,                                    /* scalar load_cost.  */
  4,                                    /* scalar_store_cost.  */
  6,                                    /* vec_stmt_cost.  */
  0,                                    /* vec_to_scalar_cost.  */
  2,                                    /* scalar_to_vec_cost.  */
  4,                                    /* vec_align_load_cost.  */
  4,                                    /* vec_unalign_load_cost.  */
  4,                                    /* vec_store_cost.  */
  2,                                    /* cond_taken_branch_cost.  */
  1,                                    /* cond_not_taken_branch_cost.  */

and thus the prologue/epilogue is not pessimized enough for the extra
branches (which are very cheap compared to the scalar and vector stmt costs).

I am still testing the patch to avoid the round-off errors and really account
scalar stmts correctly.

I suppose the EON regression should be fixed by instead avoiding the
peeling for alignment with a better idea on cost.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00053.html

C testcase:

void Set (float d, float *data)
{
  for (int i = 0; i < 8; i++)
    data[i] = d;
}

note that I didn't really verify it is that specific vectorization causing the
slowdown.  It just appears a lot in the diff.  As said we should recognize
that peeling for alignment is stupid here.  Will produce a patch for that as
well.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Performance seems to be back at Apr 2
Apr 2, 2015 16:20 UTC
    (Values: Base: 164.gzip: 1562, 175.vpr: 2384, 176.gcc: 2873, 181.mcf: 3743,
186.crafty: 2922, 197.parser: 2002, 252.eon: 4144, 255.vortex: 3345, 256.bzip2:
2221, 300.twolf: 3269 Peak: , 164.gzip: 1550, 175.vpr: 2402, 176.gcc: 2838,
181.mcf: 3810, 186.crafty: 2811, 197.parser: 1918, 252.eon: 4377, 255.vortex:
4353, 256.bzip2: 2334, 300.twolf: 3225)
Apr 2, 2015 07:20 UTC
    (Values: Base: 164.gzip: 1573, 175.vpr: 2144, 176.gcc: 2798, 181.mcf: 3739,
186.crafty: 2906, 197.parser: 1990, 252.eon: 3795, 255.vortex: 3100, 256.bzip2:
2214, 300.twolf: 3252 Peak: , 164.gzip: 1554, 175.vpr: 2402, 176.gcc: 2825,
181.mcf: 3794, 186.crafty: 2804, 197.parser: 1915, 252.eon: 4339, 255.vortex:
4350, 256.bzip2: 2344, 300.twolf: 3264)

Not sure what changed in that range

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
32bit runs still shows regression between
Feb 10, 2015 17:03 UTC
    (Values: Base: 164.gzip: 1478, 176.gcc: 3065, 181.mcf: 5127, 186.crafty:
2013, 197.parser: 2057, 252.eon: 2604, 255.vortex: 3062, 256.bzip2: 2062,
300.twolf: 3332 Peak: , 164.gzip: 1504, 181.mcf: 5178, 186.crafty: 2187,
197.parser: 2108, 255.vortex: 4408, 256.bzip2: 2201, 300.twolf: 3375)
Feb 10, 2015 08:03 UTC
    (Values: Base: 164.gzip: 1475, 176.gcc: 3064, 181.mcf: 5145, 186.crafty:
2008, 197.parser: 2056, 252.eon: 2920, 255.vortex: 3069, 256.bzip2: 2086,
300.twolf: 3335 Peak: , 164.gzip: 1473, 181.mcf: 5185, 186.crafty: 2187,
197.parser: 2115, 255.vortex: 4415, 256.bzip2: 2231, 300.twolf: 3364)

http://gcc.opensuse.org/SPEC/CINT/sb-megrez-head-64-32o-32bit/252_eon_big.png

So probably still the costmodel change?

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On April 3, 2015 6:22:48 PM GMT+02:00, "hubicka at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660
>
>--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
>Performance seems to be back at Apr 2
>Apr 2, 2015 16:20 UTC
>(Values: Base: 164.gzip: 1562, 175.vpr: 2384, 176.gcc: 2873, 181.mcf:
>3743,
>186.crafty: 2922, 197.parser: 2002, 252.eon: 4144, 255.vortex: 3345,
>256.bzip2:
>2221, 300.twolf: 3269 Peak: , 164.gzip: 1550, 175.vpr: 2402, 176.gcc:
>2838,
>181.mcf: 3810, 186.crafty: 2811, 197.parser: 1918, 252.eon: 4377,
>255.vortex:
>4353, 256.bzip2: 2334, 300.twolf: 3225)
>Apr 2, 2015 07:20 UTC
>(Values: Base: 164.gzip: 1573, 175.vpr: 2144, 176.gcc: 2798, 181.mcf:
>3739,
>186.crafty: 2906, 197.parser: 1990, 252.eon: 3795, 255.vortex: 3100,
>256.bzip2:
>2214, 300.twolf: 3252 Peak: , 164.gzip: 1554, 175.vpr: 2402, 176.gcc:
>2825,
>181.mcf: 3794, 186.crafty: 2804, 197.parser: 1915, 252.eon: 4339,
>255.vortex:
>4350, 256.bzip2: 2344, 300.twolf: 3264)
>
>Not sure what changed in that range

I patched the tester with some workaround.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Sat Apr  4 10:47:08 2015
New Revision: 221866

URL: https://gcc.gnu.org/viewcvs?rev=221866&root=gcc&view=rev
Log:
2015-04-04  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/64909
    PR tree-optimization/65660
    * tree-vectorizer.h (vect_get_known_peeling_cost): Adjust
    to take a cost vector for scalar iteration cost.
    (vect_get_single_scalar_iteration_cost): Likewise.
    * tree-vect-loop.c (vect_get_single_scalar_iteration_cost):
    Compute the scalar iteration cost into a cost vector.
    (vect_get_known_peeling_cost): Use the scalar cost vector to
    account for the cost of the peeled iterations.
    (vect_estimate_min_profitable_iters): Likewise.
    * tree-vect-data-refs.c (vect_peeling_hash_get_lowest_cost):
    Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-data-refs.c
    trunk/gcc/tree-vect-loop.c
    trunk/gcc/tree-vectorizer.h

Re: [Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[Jan Hubicka]

Thanks,
32-bit eon runs improved today, though I am not 100% sure it is ude to vectorization or the unit growth change
http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64-32o-32bit/252_eon_recent_big.png
Overall we had better scores on 32bit eon in the past however
http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64-32o-32bit/252_eon_big.png

Honza

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On April 3, 2015 8:35:00 PM GMT+02:00, rguenther at suse dot de
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660
>
>--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de>
>---
>On April 3, 2015 6:22:48 PM GMT+02:00, "hubicka at gcc dot gnu.org"
><gcc-bugzilla@gcc.gnu.org> wrote:
>>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660
>>
>>--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
>>Performance seems to be back at Apr 2
>>Apr 2, 2015 16:20 UTC
>>(Values: Base: 164.gzip: 1562, 175.vpr: 2384, 176.gcc: 2873, 181.mcf:
>>3743,
>>186.crafty: 2922, 197.parser: 2002, 252.eon: 4144, 255.vortex: 3345,
>>256.bzip2:
>>2221, 300.twolf: 3269 Peak: , 164.gzip: 1550, 175.vpr: 2402, 176.gcc:
>>2838,
>>181.mcf: 3810, 186.crafty: 2811, 197.parser: 1918, 252.eon: 4377,
>>255.vortex:
>>4353, 256.bzip2: 2334, 300.twolf: 3225)
>>Apr 2, 2015 07:20 UTC
>>(Values: Base: 164.gzip: 1573, 175.vpr: 2144, 176.gcc: 2798, 181.mcf:
>>3739,
>>186.crafty: 2906, 197.parser: 1990, 252.eon: 3795, 255.vortex: 3100,
>>256.bzip2:
>>2214, 300.twolf: 3252 Peak: , 164.gzip: 1554, 175.vpr: 2402, 176.gcc:
>>2825,
>>181.mcf: 3794, 186.crafty: 2804, 197.parser: 1915, 252.eon: 4339,
>>255.vortex:
>>4350, 256.bzip2: 2344, 300.twolf: 3264)
>>
>>Not sure what changed in that range
>
>I patched the tester with some workaround.

Now reverted and real fix committed (but that shouldn't fix it due to the back
end cost data)

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[hubicka at ucw dot cz]

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

--- Comment #11 from Jan Hubicka <hubicka at ucw dot cz> ---
Thanks,
32-bit eon runs improved today, though I am not 100% sure it is ude to
vectorization or the unit growth change
http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64-32o-32bit/252_eon_recent_big.png
Overall we had better scores on 32bit eon in the past however
http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64-32o-32bit/252_eon_big.png

Honza

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, PR56812 and thus g++.dg/vect/slp-pr56812.cc looks suspiciously similar.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-07
     Ever confirmed|0                           |1

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Indeed g++.dg/vect/slp-pr56812.cc FAILs with -march=bdver2 because we loop
vectorize the testcase (not wrong, but wrong is that we vectorize it by
applying peeling for alignment).

On the tester I tested a "simple"

Index: gcc/tree-vect-data-refs.c
===================================================================
--- gcc/tree-vect-data-refs.c   (revision 221808)
+++ gcc/tree-vect-data-refs.c   (working copy)
@@ -1548,7 +1548,7 @@ vect_enhance_data_refs_alignment (loop_v
       && all_misalignments_unknown
       && LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)
       && (LOOP_VINFO_INT_NITERS (loop_vinfo)
-         < 2 * (unsigned) LOOP_VINFO_VECT_FACTOR (loop_vinfo) - 1))
+         < 3 * (unsigned) LOOP_VINFO_VECT_FACTOR (loop_vinfo) - 1))
     do_peeling = false;

   if (do_peeling

but at this stage this will have too much testsuite fallout (in archs I
did not test).

The "real" fix is to apply similar cost considerations as the final cost model
does when deciding peeling for alignment (which is hardly profitable on most
archs).

A good fix restricted to bdver2 is to increase the suspiciously low cost of
taken/not taken branches.  I am going to propose a patch doing that.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Patch posted.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Tue Apr  7 13:40:24 2015
New Revision: 221895

URL: https://gcc.gnu.org/viewcvs?rev=221895&root=gcc&view=rev
Log:
2015-04-07  Richard Biener  <rguenther@suse.de>

    Backport from mainline
    2015-04-04  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/64909
    PR tree-optimization/65660
    * tree-vectorizer.h (vect_get_known_peeling_cost): Adjust
    to take a cost vector for scalar iteration cost.
    (vect_get_single_scalar_iteration_cost): Likewise.
    * tree-vect-loop.c (vect_get_single_scalar_iteration_cost):
    Compute the scalar iteration cost into a cost vector.
    (vect_get_known_peeling_cost): Use the scalar cost vector to
    account for the cost of the peeled iterations.
    (vect_estimate_min_profitable_iters): Likewise.
    * tree-vect-data-refs.c (vect_peeling_hash_get_lowest_cost):
    Likewise.

Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/tree-vect-data-refs.c
    branches/gcc-4_9-branch/gcc/tree-vect-loop.c
    branches/gcc-4_9-branch/gcc/tree-vectorizer.h

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Note that the eon performance is low even on frescobaldi tester (that is
pre-bulldozer). The regression is in range:
Oct 18, 2012 23:47 UTC
    (Values: Base: 164.gzip: 1202, 175.vpr: 1247, 176.gcc: 1677, 181.mcf: 867,
186.crafty: 2230, 197.parser: 997, 252.eon: 2100, 253.perlbmk: 1797, 254.gap:
1555, 255.vortex: 1865, 256.bzip2: 1282, 300.twolf: 1557, SPECint: 1475 Peak: ,
164.gzip: 1253, 175.vpr: 1289, 176.gcc: 1659, 181.mcf: 865, 186.crafty: 2208,
197.parser: 1067, 252.eon: 2753, 253.perlbmk: 1920, 254.gap: 1617, 255.vortex:
1875, 256.bzip2: 1296, 300.twolf: 1559, SPECint: 1541)
Oct 17, 2012 16:01 UTC
    (Values: Base: 164.gzip: 1220, 175.vpr: 1249, 176.gcc: 1655, 181.mcf: 871,
186.crafty: 2248, 197.parser: 996, 252.eon: 2490, 253.perlbmk: 1807, 254.gap:
1558, 255.vortex: 1856, 256.bzip2: 1274, 300.twolf: 1554, SPECint: 1497 Peak: ,
164.gzip: 1257, 175.vpr: 1304, 176.gcc: 1654, 181.mcf: 863, 186.crafty: 2240,
197.parser: 1065, 252.eon: 2785, 253.perlbmk: 1920, 254.gap: 1604, 255.vortex:
1858, 256.bzip2: 1284, 300.twolf: 1552, SPECint: 1538)

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Actually it seems that the tester was used to test the change and it was
applied at
Nov 7, 2012 03:02 UTC
    (Values: Base: 164.gzip: 1269, 175.vpr: 1245, 176.gcc: 1627, 181.mcf: 868,
186.crafty: 2219, 197.parser: 1020, 252.eon: 1942, 253.perlbmk: 1784, 254.gap:
1558, 255.vortex: 1861, 256.bzip2: 1277, 300.twolf: 1547, SPECint: 1468 Peak: ,
164.gzip: 1323, 175.vpr: 1300, 176.gcc: 1655, 181.mcf: 868, 186.crafty: 2235,
197.parser: 1038, 252.eon: 2760, 253.perlbmk: 1938, 254.gap: 1606, 255.vortex:
1867, 256.bzip2: 1290, 300.twolf: 1556, SPECint: 1546)
Nov 6, 2012 08:00 UTC
    (Values: Base: 164.gzip: 1264, 175.vpr: 1239, 176.gcc: 1630, 181.mcf: 856,
186.crafty: 2222, 197.parser: 991, 252.eon: 2461, 253.perlbmk: 1783, 254.gap:
1556, 255.vortex: 1864, 256.bzip2: 1275, 300.twolf: 1551, SPECint: 1492 Peak: ,
164.gzip: 1322, 175.vpr: 1293, 176.gcc: 1657, 181.mcf: 864, 186.crafty: 2244,
197.parser: 1049, 252.eon: 2716, 253.perlbmk: 1916, 254.gap: 1614, 255.vortex:
1880, 256.bzip2: 1299, 300.twolf: 1556, SPECint: 1544)

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #17)
> Actually it seems that the tester was used to test the change and it was
> applied at

Note that frescobaldi (or vangelis) both don't use -march=native and thus
are using generic tuning and bare SSE2.  The regression seen has nothing
to do with $summary.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Yep, but if you can look up the revision range, I would like to know what
happened.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #17)
> Actually it seems that the tester was used to test the change and it was
> applied at
> Nov 7, 2012 03:02 UTC
>     (Values: Base: 164.gzip: 1269, 175.vpr: 1245, 176.gcc: 1627, 181.mcf:
> 868, 186.crafty: 2219, 197.parser: 1020, 252.eon: 1942, 253.perlbmk: 1784,
> 254.gap: 1558, 255.vortex: 1861, 256.bzip2: 1277, 300.twolf: 1547, SPECint:
> 1468 Peak: , 164.gzip: 1323, 175.vpr: 1300, 176.gcc: 1655, 181.mcf: 868,
> 186.crafty: 2235, 197.parser: 1038, 252.eon: 2760, 253.perlbmk: 1938,
> 254.gap: 1606, 255.vortex: 1867, 256.bzip2: 1290, 300.twolf: 1556, SPECint:
> 1546)
> Nov 6, 2012 08:00 UTC
>     (Values: Base: 164.gzip: 1264, 175.vpr: 1239, 176.gcc: 1630, 181.mcf:
> 856, 186.crafty: 2222, 197.parser: 991, 252.eon: 2461, 253.perlbmk: 1783,
> 254.gap: 1556, 255.vortex: 1864, 256.bzip2: 1275, 300.twolf: 1551, SPECint:
> 1492 Peak: , 164.gzip: 1322, 175.vpr: 1293, 176.gcc: 1657, 181.mcf: 864,
> 186.crafty: 2244, 197.parser: 1049, 252.eon: 2716, 253.perlbmk: 1916,
> 254.gap: 1614, 255.vortex: 1880, 256.bzip2: 1299, 300.twolf: 1556, SPECint:
> 1544)

r193208 (good) to r193279 (bad)

my bet is either inlining or the unrolling change (though -O2 -ffast-math
shouldn't unroll too much).

[Bug target/65660] [5/6 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon Apr 13 07:33:51 2015
New Revision: 222040

URL: https://gcc.gnu.org/viewcvs?rev=222040&root=gcc&view=rev
Log:
2015-04-13  Richard Biener  <rguenther@suse.de>

    PR target/65660
    * config/i386/i386.c (bdver1_cost): Double cond_taken_branch_cost
    and cond_not_taken_branch_cost to 4 and 2.
    (bdver2_cost): Likewise.
    (bdver3_cost): Likewise.
    (bdver4_cost): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |6.0
            Summary|[5/6 Regression] 252.eon    |[5 Regression] 252.eon
                   |regression on bdver2 with   |regression on bdver2 with
                   |-Ofast                      |-Ofast

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast

[rguenth at gcc dot gnu.org]

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

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

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

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