From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-479348-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 51567 invoked by alias); 4 Mar 2015 13:55:18 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 51505 invoked by uid 55); 4 Mar 2015 13:55:15 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1
Date: Wed, 04 Mar 2015 13:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: testsuite
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63175-4-Q0XmIcK5nr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63175-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63175-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg00492.txt.bz2

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

--- Comment #33 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 4 Mar 2015, dje at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
> 
> --- Comment #32 from David Edelsohn <dje at gcc dot gnu.org> ---
> "So currently on a tie we don't vectorize basic-blocks (same with GCC 4.8).
> That's kind of arbitrary, but given instruction encoding size on x86 for
> example
> it makes sense."

That was just a random comment and not the design decision for that code.
If costs are near tie then it becomes quite arbitrary given the very very
simple cost modeling of the scalar code.

That we choose to keep the scalar code in case the cost model says its
equally expensive than the vectorized code is an arbitrary choice.

I wonder if in this particular case the vectorized or the scalar version
is faster (on ppc)?