[Bug tree-optimization/56935] New: Basic block is not SLP-vectorizeed after r197635.

[Bug tree-optimization/56935] New: Basic block is not SLP-vectorizeed after r197635.

[ysrumyan at gmail dot com]

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

             Bug #: 56935
           Summary: Basic block is not SLP-vectorizeed after r197635.
    Classification: Unclassified
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ysrumyan@gmail.com


It looks that after cost model changing some performance opportunities were
lost.
It can be seen for the attached test-case:

before this change
t.c:29: note: Cost model analysis: 
  Vector inside of basic block cost: 5
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar cost of basic block: 6
t.c:29: note: Basic block will be vectorized using SLP
 after this change
t.c:29: note: Cost model analysis: 
  Vector inside of basic block cost: 5
  Vector prologue cost: 1
  Vector epilogue cost: 0
  Scalar cost of basic block: 6
t.c:29: note: not vectorized: vectorization is not profitable.

Note that this test was extracted from 253.perlbench (spec2000) for which we
got -4.5% performance degradation on corei7 (with avx).

[Bug tree-optimization/56935] Basic block is not SLP-vectorizeed after r197635.

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev <ysrumyan at gmail dot com> 2013-04-12 14:01:50 UTC ---
Created attachment 29862
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29862
testcase

Need to be compiled with the following options:
-O3 -mavx -march=corei7

[Bug tree-optimization/56935] Basic block is not SLP-vectorizeed after r197635.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-04-15
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-15 10:27:55 UTC ---
I will have a look.  We now _do_ account for some costs more appropriately
(well, I think so ;)).

[Bug tree-optimization/56935] Basic block is not SLP-vectorizeed after r197635.

[ysrumyan at gmail dot com]

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

--- Comment #4 from Yuri Rumyantsev <ysrumyan at gmail dot com> 2013-04-15 14:54:50 UTC ---
Richard,

both subq's are accessed the same cash line and it means that after 1st store
tthe 2nd load will stall till finish updating data cash (this is not exact
explanation but if you'd like I can find out more strong and correct definition
of memory conflict). In result non-vectorizable code will run much slower adn
we saw such slowdown on 253.perl from cpu2000.

[Bug tree-optimization/56935] Basic block is not SLP-vectorizeed after r197635.

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> 2013-04-16 07:48:47 UTC ---
On Mon, 15 Apr 2013, ysrumyan at gmail dot com wrote:

> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56935
> 
> --- Comment #4 from Yuri Rumyantsev <ysrumyan at gmail dot com> 2013-04-15 14:54:50 UTC ---
> Richard,
> 
> both subq's are accessed the same cash line and it means that after 1st 
> store tthe 2nd load will stall till finish updating data cash (this is 
> not exact explanation but if you'd like I can find out more strong and 
> correct definition of memory conflict). In result non-vectorizable code 
> will run much slower adn we saw such slowdown on 253.perl from cpu2000.

I fear this is beyond the scope of the vectorizer cost model in
its current form.  Clearly what it computes is correct if the
cost is defined as a sum of individual stmt costs (which is
how the scalar cost is computed).  The vectorizer cost model
now gives the target the power to look at the whole vectorized
sequence and compute something better than the sum of the individual
vectorized stmt costs, but currently the x86 target does not
use this power.

Factoring in instruction cache it's still not clear that a possible
extra cache miss for ifetch is worth avoiding the "stall" due to
the store forwarding issue.  (btw, your explanation looks odd -
there is no dependency between the two - yes, if the share the
same slot as the store buffers granularity then maybe a failed
store forward (due to _no_ dependency) may cause that issue?)

Note that for basic-block vectorization we want to even more
keep an eye on code-size, and the same cost model is used for
basic-block and loop SLP.

Richard.

[Bug tree-optimization/56935] Basic block is not SLP-vectorizeed after r197635.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-22 14:47:54 UTC ---
Ok.