[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

[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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|regression                  |testsuite
   Target Milestone|---                         |4.9.2

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Try -fno-common - the store is also misaligned otherwise as 'out' is a common.
We've fixed 4.9 to no longer align commons (because we can't do that reliably).
IIRC the vectorizer testsuite was "fixed" to pass -fno-common everywhere but
apperantly some tests were missed?

[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

[jakub at gcc dot gnu.org]

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

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

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

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

[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

[rguenth at gcc dot gnu.org]

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

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

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

[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

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

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

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
The test fails even on ppc64 because it looks for the string "basic block
vectorized using SLP" in the tree-slp-details dump but no such string is
emitted by GCC (it was removed in revision 199620 without adjusting the test). 
The closest strings that are in the costmodel-bb-slp-9a.c.136t.slp2 file are
the following two:

/home/remote/msebor/fsf/gcc/trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c:20:13:
note: Basic block will be vectorized using SLP
/home/remote/msebor/fsf/gcc/trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c:20:13:
note: basic block vectorized

Replacing the existing string with one of the two above lets the test pass.

[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

[macro@linux-mips.org]

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

--- Comment #5 from Maciej W. Rozycki <macro@linux-mips.org> ---
But the point is not the missing string, but a missed optimisation.
Has the optimisation been brought back now?

NB I have no way to look into it anymore.

[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

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Maciej W. Rozycki from comment #5)

It doesn't look like things have changed since 4.9.0.  I just posted my
analysis to the list:
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01401.html

[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

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
The regression was introduced in this commit:

commit 9eec20bfd5806dd0380e07dbc0f03409ce3d4efb
Author: rguenth <rguenth@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Tue Mar 26 09:14:59 2013 +0000

    2013-03-26  Richard Biener  <rguenther@suse.de>

        * emit-rtl.c (set_mem_attributes_minus_bitpos): Remove
        alignment computations and rely on get_object_alignment_1
        for the !TYPE_P case.
        Commonize DECL/COMPONENT_REF handling in the ARRAY_REF path.


    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@197095
138bc75d-0d04-0410-961f-82ee72b054a4

[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

[rguenth at gcc dot gnu.org]

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

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looking at the original description - note that copying cannot be optimized
away, the accesses are to global variables (well, unless you build with -flto
or -fwhole-program which will privatize the stmts).

But of course the "correctness" test is optimized away very early.  So the
testcase should get a __asm__ volatile ("" : : "memory"); inbetween the
copying and the correctness verification.

Currently vectorization is entered with the IL

  <bb 2>:
  _8 = MEM[(unsigned int *)&in + 4B];
  MEM[(unsigned int *)&out] = _8;
  _14 = MEM[(unsigned int *)&in + 8B];
  MEM[(unsigned int *)&out + 4B] = _14;
  _20 = MEM[(unsigned int *)&in + 12B];
  MEM[(unsigned int *)&out + 8B] = _20;
  _26 = MEM[(unsigned int *)&in + 16B];
  MEM[(unsigned int *)&out + 12B] = _26;
  return 0;

(see - no check anymore)

We generate (with -mcpu=e6500 -m64 -maltivec -mabi=altivec, just to pick one
example)

  <bb 2>:
  vect__2.12_11 = __builtin_altivec_mask_for_load (&MEM[(unsigned int *)&in +
4B]);
  vectp.14_13 = &MEM[(unsigned int *)&in + 4B] & -16B;
  vect__2.15_14 = MEM[(unsigned int *)vectp.14_13];
  vectp.14_16 = &MEM[(void *)&in + 16B] & -16B;
  vect__2.16_17 = MEM[(unsigned int *)vectp.14_16];
  vect__2.17_18 = REALIGN_LOAD <vect__2.15_14, vect__2.16_17, vect__2.12_11>;
  MEM[(unsigned int *)&out] = vect__2.17_18;
  return 0;

and

(insn 16 15 17 (set (subreg:DI (reg:V4SI 171 [ vect__2.15 ]) 8)
        (mem:DI (plus:DI (reg:DI 170)
                (const_int 8 [0x8])) [1 MEM[(unsigned int *)&MEM[(unsigned int
*)&in + 4B] & -16B]+8 S8 A32])) t.c:14 -1
     (nil))

(insn 17 16 18 (set (subreg:DI (reg:V4SI 171 [ vect__2.15 ]) 0)
        (mem:DI (reg:DI 170) [1 MEM[(unsigned int *)&MEM[(unsigned int *)&in +
4B] & -16B]+0 S8 A32])) t.c:14 -1
     (nil))

(insn 21 20 22 (set (reg:V4SI 176)
        (mem:V4SI (reg:DI 174) [1 MEM[(unsigned int *)&MEM[(void *)&in + 16B] &
-16B]+0 S16 A128])) t.c:14 -1
     (nil))

so for some reason we expand the first aligned load using two DI loads.

Investigating.

I have a fix which ends up producing

.L.main1:
        addis 9,2,.LANCHOR0@toc@ha
        li 3,0
        addi 9,9,.LANCHOR0@toc@l
        addi 10,9,4
        addi 9,9,16
        neg 8,10
        lvx 0,0,9
        lvsr 13,0,8
        addis 9,2,.LANCHOR1@toc@ha
        lvx 1,0,10
        addi 9,9,.LANCHOR1@toc@l
        vperm 0,1,0,13
        stvx 0,0,9
        blr

not sure if that is the same as with 4.8 though (don't have a cross ready
to verify - but the RTL looks good).

[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

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 34878
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34878&action=edit
patch

I am testing the following (further testing appreciated).

[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

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Fri Feb 27 08:37:51 2015
New Revision: 221043

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

    PR middle-end/63175
    * builtins.c (get_object_alignment_2): Make sure to re-apply
    the ANDed mask after recursing to its operand gets us a new
    misalignment bit position.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c

[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

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Code quality regression fixed for trunk(?).  Testcase is of course still
"bogus"
(wrong scan-dump, doesn't really test the code quality).

[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

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed as far as I am concerned.  Please somebody else fix the testcase itself.

[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

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Fri Feb 27 10:32:14 2015
New Revision: 221052

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

    PR middle-end/63175
    * builtins.c (get_object_alignment_2): Make sure to re-apply
    the ANDed mask after recursing to its operand gets us a new
    misalignment bit position.

Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/builtins.c

[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

[msebor at gcc dot gnu.org]

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

--- Comment #14 from Martin Sebor <msebor at gcc dot gnu.org> ---
Richard, thank you for the patch.  It resolves the regression in the quality of
the code generated for the test on ppc64 (I am yet to test other ppc variants).
 Unfortunately, while working on an improved test for the vectorization I
uncovered another regression in this area that manifests itself when the
destination address (as opposed to the source address) is not aligned as
expected.  I posted the enhanced test to the list:
http://gcc.gnu.org/ml/gcc-patches/2015-02/msg01736.html

[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

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, first of all unaligned stores are not supported according to the targets
vectorization hook, thus you'd need to peel the loop to make the store aligned
which for some reason doesn't happen.  But when peeled you certainly will see
byte/short/word stores at least.

[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

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #15)
> Btw, first of all unaligned stores are not supported according to the targets
> vectorization hook, thus you'd need to peel the loop to make the store
> aligned
> which for some reason doesn't happen.

Quite obvious - the loop iterates 8 times but the vectorization factor is 8
as well, so if we peel off a iteration to align the destination the vectorized
loop will never enter.

Why is the loop bound to i != 16 / sizeof *s?

>  But when peeled you certainly will see
> byte/short/word stores at least.

Like when I increase the iteration count I get for copy_short_0_1:

.L.copy_Type_0_1:
        addis 6,2,.LANCHOR0@toc@ha
        addis 7,2,.LANCHOR1@toc@ha
        addi 6,6,.LANCHOR0@toc@l
        addi 7,7,.LANCHOR1@toc@l
        li 8,7
        addi 9,6,2
        mr 10,7
        mtctr 8
        .p2align 4,,15
.L2:
        addi 10,10,2
        lhz 8,-2(10)
        addi 9,9,2
        sth 8,-2(9)
        bdnz .L2
        addi 8,7,14
        addi 7,7,29
        neg 5,8
        lvx 1,0,8
        lvx 0,0,7
        li 7,16
        lvsr 13,0,5
        addi 8,10,14
        addi 9,9,14
        addi 10,10,16
        vperm 0,1,0,13
        stvx 0,6,7
        .p2align 4,,15
.L3:
        lhzu 7,2(8)
        cmpld 7,10,8
        sthu 7,2(9)
        bne+ 7,.L3
        blr

the cost model should probably reject this, but it does not:

t.c:36:1: note: Cost model analysis:
  Vector inside of loop cost: 3
  Vector prologue cost: 17
  Vector epilogue cost: 2
  Scalar iteration cost: 2
  Scalar outside cost: 0
  Vector outside cost: 19
  prologue iterations: 7
  epilogue iterations: 1
  Calculated minimum iters for profitability: 10

[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

[msebor at gcc dot gnu.org]

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

--- Comment #17 from Martin Sebor <msebor at gcc dot gnu.org> ---
Following up on my comment #14, and as requested on gcc-patches, the test case
below is vectorized with GCC 4.8.2 for T being either 32 bits wide (e.g., int)
or 64-bits wide (e.g., long or long long) but not with the fix referenced in
comment #13.  The difference between the test in costmodel-bb-slp-9a.c and the
code here is that unlike the source, the destination of the copy isn't aligned
on an even element boundary.

const T a [] = { 1, 2, 3, 4, 5 };
extern T b[sizeof a / sizeof *a];

void g (void)
{
    const T *p = a;
    T *q = b + 1;

    *q++ = *p++;
    *q++ = *p++;
    *q++ = *p++;
    *q++ = *p++;
}

In addition to this failure (mentioned on the list) the latest trunk also fails
to vectorize the following code which is successfully vectorized by 4.8.2.  The
difference is that the arrays are only declared here while in
costmodel-bb-slp-9a.c they are defined.  I only noticed this now, and so it's
not being exercised in the proposed enhanced test submitted to gcc-patches last
Friday,

extern const T a [];
extern T b[];

void g (void)
{
    const T *p = a + 1;
    T *q = b;

    *q++ = *p++;
    *q++ = *p++;
    *q++ = *p++;
    *q++ = *p++;
}

[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

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 2 Mar 2015, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
> 
> --- Comment #17 from Martin Sebor <msebor at gcc dot gnu.org> ---
> Following up on my comment #14, and as requested on gcc-patches, the test case
> below is vectorized with GCC 4.8.2 for T being either 32 bits wide (e.g., int)
> or 64-bits wide (e.g., long or long long) but not with the fix referenced in
> comment #13.  The difference between the test in costmodel-bb-slp-9a.c and the
> code here is that unlike the source, the destination of the copy isn't aligned
> on an even element boundary.
> 
> const T a [] = { 1, 2, 3, 4, 5 };
> extern T b[sizeof a / sizeof *a];
> 
> void g (void)
> {
>     const T *p = a;
>     T *q = b + 1;
> 
>     *q++ = *p++;
>     *q++ = *p++;
>     *q++ = *p++;
>     *q++ = *p++;
> }
> 
> In addition to this failure (mentioned on the list) the latest trunk also fails
> to vectorize the following code which is successfully vectorized by 4.8.2.  The
> difference is that the arrays are only declared here while in
> costmodel-bb-slp-9a.c they are defined.  I only noticed this now, and so it's
> not being exercised in the proposed enhanced test submitted to gcc-patches last
> Friday,
> 
> extern const T a [];
> extern T b[];
> 
> void g (void)
> {
>     const T *p = a + 1;
>     T *q = b;
> 
>     *q++ = *p++;
>     *q++ = *p++;
>     *q++ = *p++;
>     *q++ = *p++;
> }

Both is because powerpc simply cannot handle unaligned stores and
in neither testcase we can force its alignemnt (it's "extern", and
for the first case aligning the first element won't align the
vector store)

[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

[rguenther at suse dot de]

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

--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 2 Mar 2015, rguenther at suse dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
> 
> --- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
> On Mon, 2 Mar 2015, msebor at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
> > 
> > --- Comment #17 from Martin Sebor <msebor at gcc dot gnu.org> ---
> > Following up on my comment #14, and as requested on gcc-patches, the test case
> > below is vectorized with GCC 4.8.2 for T being either 32 bits wide (e.g., int)
> > or 64-bits wide (e.g., long or long long) but not with the fix referenced in
> > comment #13.  The difference between the test in costmodel-bb-slp-9a.c and the
> > code here is that unlike the source, the destination of the copy isn't aligned
> > on an even element boundary.
> > 
> > const T a [] = { 1, 2, 3, 4, 5 };
> > extern T b[sizeof a / sizeof *a];
> > 
> > void g (void)
> > {
> >     const T *p = a;
> >     T *q = b + 1;
> > 
> >     *q++ = *p++;
> >     *q++ = *p++;
> >     *q++ = *p++;
> >     *q++ = *p++;
> > }
> > 
> > In addition to this failure (mentioned on the list) the latest trunk also fails
> > to vectorize the following code which is successfully vectorized by 4.8.2.  The
> > difference is that the arrays are only declared here while in
> > costmodel-bb-slp-9a.c they are defined.  I only noticed this now, and so it's
> > not being exercised in the proposed enhanced test submitted to gcc-patches last
> > Friday,
> > 
> > extern const T a [];
> > extern T b[];
> > 
> > void g (void)
> > {
> >     const T *p = a + 1;
> >     T *q = b;
> > 
> >     *q++ = *p++;
> >     *q++ = *p++;
> >     *q++ = *p++;
> >     *q++ = *p++;
> > }
> 
> Both is because powerpc simply cannot handle unaligned stores and
> in neither testcase we can force its alignemnt (it's "extern", and
> for the first case aligning the first element won't align the
> vector store)

How does GCC 4.8 generated vectorized code look like?

[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

[msebor at gcc dot gnu.org]

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

--- Comment #20 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #19)

Please remove the extern from the first test and try again (it's a vestige of
the second test).  Here's the assembly emitted by 4.8.3 for the first test
(without the extern):

$ cat u.c && gcc -DT="int" -O2 -ftree-vectorize -maltivec -S u.c && cat u.s
const T a [] = { 1, 2, 3, 4, 5 };
T b[sizeof a / sizeof *a];

void g (void)
{
    const T *p = a;
    T *q = b + 1;

    *q++ = *p++;
    *q++ = *p++;
    *q++ = *p++;
    *q++ = *p++;
}
    .file    "u.c"
    .section    ".toc","aw"
    .section    ".text"
    .section    ".toc","aw"
.LC0:
    .quad    b
    .section    ".text"
    .align 2
    .p2align 4,,15
    .globl g
    .section    ".opd","aw"
    .align 3
g:
    .quad    .L.g,.TOC.@tocbase
    .previous
    .type    g, @function
.L.g:
    addis 9,2,.LC1@toc@ha
    addis 10,2,.LC0@toc@ha
    addi 9,9,.LC1@toc@l
    lxvw4x 32,0,9
    ld 9,.LC0@toc@l(10)
    li 10,4
    stxvw4x 32,9,10
    blr
    .long 0
    .byte 0,0,0,0,0,0,0,0
    .size    g,.-.L.g
    .comm    b,20,4
    .globl a
    .section    .rodata
    .align 4
    .type    a, @object
    .size    a, 20
a:
    .long    1
    .long    2
    .long    3
    .long    4
    .long    5
    .section    .rodata.cst16,"aM",@progbits,16
    .align 4
.LC1:
    .4byte    1
    .4byte    2
    .4byte    3
    .4byte    4
    .ident    "GCC: (GNU) 4.8.3 20140911 (Red Hat 4.8.3-9)"
    .section    .note.GNU-stack,"",@progbits

[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

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> ---
On March 2, 2015 5:58:28 PM CET, "msebor at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
>
>--- Comment #20 from Martin Sebor <msebor at gcc dot gnu.org> ---
>(In reply to rguenther@suse.de from comment #19)
>
>Please remove the extern from the first test and try again (it's a
>vestige of
>the second test).  Here's the assembly emitted by 4.8.3 for the first
>test
>(without the extern):
>
>$ cat u.c && gcc -DT="int" -O2 -ftree-vectorize -maltivec -S u.c && cat
>u.s
>const T a [] = { 1, 2, 3, 4, 5 };
>T b[sizeof a / sizeof *a];
>
>void g (void)
>{
>    const T *p = a;
>    T *q = b + 1;
>
>    *q++ = *p++;
>    *q++ = *p++;
>    *q++ = *p++;
>    *q++ = *p++;
>}
>    .file    "u.c"
>    .section    ".toc","aw"
>    .section    ".text"
>    .section    ".toc","aw"
>.LC0:
>    .quad    b
>    .section    ".text"
>    .align 2
>    .p2align 4,,15
>    .globl g
>    .section    ".opd","aw"
>    .align 3
>g:
>    .quad    .L.g,.TOC.@tocbase
>    .previous
>    .type    g, @function
>.L.g:
>    addis 9,2,.LC1@toc@ha
>    addis 10,2,.LC0@toc@ha
>    addi 9,9,.LC1@toc@l
>    lxvw4x 32,0,9
>    ld 9,.LC0@toc@l(10)
>    li 10,4
>    stxvw4x 32,9,10

But isn't this simply wrong-code?!

>    blr
>    .long 0
>    .byte 0,0,0,0,0,0,0,0
>    .size    g,.-.L.g
>    .comm    b,20,4
>    .globl a
>    .section    .rodata
>    .align 4
>    .type    a, @object
>    .size    a, 20
>a:
>    .long    1
>    .long    2
>    .long    3
>    .long    4
>    .long    5
>    .section    .rodata.cst16,"aM",@progbits,16
>    .align 4
>.LC1:
>    .4byte    1
>    .4byte    2
>    .4byte    3
>    .4byte    4
>    .ident    "GCC: (GNU) 4.8.3 20140911 (Red Hat 4.8.3-9)"
>    .section    .note.GNU-stack,"",@progbits

[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

[msebor at gcc dot gnu.org]

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

--- Comment #22 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #21)
> >g:
> >    .quad    .L.g,.TOC.@tocbase
> >    .previous
> >    .type    g, @function
> >.L.g:
> >    addis 9,2,.LC1@toc@ha
> >    addis 10,2,.LC0@toc@ha
> >    addi 9,9,.LC1@toc@l
> >    lxvw4x 32,0,9
> >    ld 9,.LC0@toc@l(10)
> >    li 10,4
> >    stxvw4x 32,9,10
> 
> But isn't this simply wrong-code?!

I don't see anything wrong with it.  The load seems straightforward enough and,
AFAICS, the store code matches the stxvw4x example in the PowerISA 2.07
reference (in Storing an Unaligned Quadword to Big-Endian Storage on page 360).
 r9 is the address of B and r10 is the byte offset of B[1] from B.

[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

[rguenther at suse dot de]

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

--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> ---
On March 2, 2015 7:13:25 PM CET, "msebor at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
>
>--- Comment #22 from Martin Sebor <msebor at gcc dot gnu.org> ---
>(In reply to rguenther@suse.de from comment #21)
>> >g:
>> >    .quad    .L.g,.TOC.@tocbase
>> >    .previous
>> >    .type    g, @function
>> >.L.g:
>> >    addis 9,2,.LC1@toc@ha
>> >    addis 10,2,.LC0@toc@ha
>> >    addi 9,9,.LC1@toc@l
>> >    lxvw4x 32,0,9
>> >    ld 9,.LC0@toc@l(10)
>> >    li 10,4
>> >    stxvw4x 32,9,10
>> 
>> But isn't this simply wrong-code?!
>
>I don't see anything wrong with it.  The load seems straightforward
>enough and,
>AFAICS, the store code matches the stxvw4x example in the PowerISA 2.07
>reference (in Storing an Unaligned Quadword to Big-Endian Storage on
>page 360).
> r9 is the address of B and r10 is the byte offset of B[1] from B.

Ah, i only tested with altivec as noted in the bug description. I'll check with
vsx tomorrow.

[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

[msebor at gcc dot gnu.org]

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

--- Comment #24 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #16)
> Why is the loop bound to i != 16 / sizeof *s?

The upper bound is intended to make the copied sequence fit into one vector
register, irrespective of the size of the array element.

The vector load and store instructions tolerate unaligned accesses and there
are permute instructions that combine the contents of two vector registers into
a single one to compensate for unaligned reads or writes.  I'm not sure it
makes sense to expect unaligned copies involving a single vector register's
worth of data to be vectorized (as done in my proposed tests for char and
short), but I would expect larger unaligned copies (i.e., multiples of 16
bytes) to benefit from it.  In my experiments I've seen no evidence of GCC
attempting to vectorize such copies but I need to do some more research to
understand why.

(In reply to comment #23)

The test uses -maltivec and that's what I've been using as well.  But I see in
the Power ISA book that lxvw4x and stxvw4x are classified as VSX instructions,
so perhaps they shouldn't be emitted without -mvsx.  Although 5.0 doesn't emit
them even with -vsx.

[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

[rguenther at suse dot de]

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

--- Comment #25 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 3 Mar 2015, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
> 
> --- Comment #24 from Martin Sebor <msebor at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #16)
> > Why is the loop bound to i != 16 / sizeof *s?
> 
> The upper bound is intended to make the copied sequence fit into one vector
> register, irrespective of the size of the array element.
> 
> The vector load and store instructions tolerate unaligned accesses and there
> are permute instructions that combine the contents of two vector registers into
> a single one to compensate for unaligned reads or writes.  I'm not sure it
> makes sense to expect unaligned copies involving a single vector register's
> worth of data to be vectorized (as done in my proposed tests for char and
> short), but I would expect larger unaligned copies (i.e., multiples of 16
> bytes) to benefit from it.  In my experiments I've seen no evidence of GCC
> attempting to vectorize such copies but I need to do some more research to
> understand why.
> 
> (In reply to comment #23)
> 
> The test uses -maltivec and that's what I've been using as well.  But I 
> see in the Power ISA book that lxvw4x and stxvw4x are classified as VSX 
> instructions, so perhaps they shouldn't be emitted without -mvsx.  
> Although 5.0 doesn't emit them even with -vsx.

5.0 doesn't consider stxvw4x without -mvsx - it does so with but then
the vectorizer cost model says the vectorization is not profitable:

t.c:10:10: note: Cost model analysis:
  Vector inside of basic block cost: 29
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar cost of basic block: 8
t.c:10:10: note: not vectorized: vectorization is not profitable.

I'll see if that cost caluclation is sensible.  We have 2 aligned
vector loads (cost 2), one permute (cost 3), one vector stmt (cost 1),
one unaligned store (unknown misalignment) which hits

rs6000_builtin_vectorization_cost (type_of_cost=unaligned_store, 
    vectype=<vector_type 0x7ffff6a39888>, misalign=-1)
    at /space/rguenther/src/svn/trunk2/gcc/config/rs6000/rs6000.c:4376
4376      switch (type_of_cost)
...
4455                        case -1:
4456                          /* Unknown misalignment.  */
4457                        case 4:
4458                        case 12:
4459                          /* Word aligned.  */
4460                          return 23;

cost of 23!(??).  For a misalign of 4?

Well - there you have it.  For the testcase

#define T int
extern const T a [];
T b[8];

void g (void)
{
  const T *p = a + 1;
  T *q = b + 1;

  *q++ = *p++;
  *q++ = *p++;
  *q++ = *p++;
  *q++ = *p++;
}

Eventually 4.8 had the cost model turned off for the testsuite or
it had bugs and misrepresented the case.  But clearly a cost of
23 looks excessive to me here (the scalar store of one of the 4
elements has cost 1!  so the unaligned vector store is nearly
6 times more expensive than doing the 4 unaligned stores.  Nobody
would design an instruction with such a severe penalty).

With -fvect-cost-model=unlimited GCC 5 produces

.L.g:
        addis 9,2,.LC0@toc@ha           # gpr load fusion, type long
        ld 9,.LC0@toc@l(9)
        addis 8,2,.LANCHOR0@toc@ha
        addi 8,8,.LANCHOR0@toc@l
        addi 10,9,12
        neg 7,9
        rldicr 10,10,0,59
        rldicr 9,9,0,59
        lvsr 13,0,7
        lxvw4x 33,0,9
        lxvw4x 32,0,10
        li 9,4
        vperm 0,1,0,13
        stxvw4x 32,8,9
        blr

Ah, GCC 4.8 had the cost model disabled by default (at least for
basic-block vectorization), so you need to enable it via
-fvect-cost-model where it rejects vectorizing the above with the
same reasoning.

So there is no regression and if vectorization is profitable then
the backend needs to adjust its cost model.

[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

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
David - please clarify the cost of misaligned stores/loads.  I tried to
understand the PPC ISA document but can't really find the appropriate place
where it talks about misalign cost (I only can see it still assumes element
alignment).

Btw with double-word alignment I get

t.c:10:10: note: Cost model analysis:
  Vector inside of basic block cost: 8
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar cost of basic block: 8
t.c:10:10: note: not vectorized: vectorization is not profitable.

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.  Note that we seem to prefer optimized re-alignment loads
over misaligned loads (even if double-word aligned) - the vectorizer is not set
up to decide that based on costs (the misaligned load would cost 2 while
the optimized re-aligned load costs 6 - two aligned loads (2), one vector stmt
for mask compute (1) and one permute (3)).

I think we are regression free compared to 4.8 (if you enable -fvect-cost-model
there).

[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

[dje at gcc dot gnu.org]

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

--- Comment #27 from David Edelsohn <dje at gcc dot gnu.org> ---
The vector alignment cost varies with processor implementation, not defined by
the architecture.  Bill has a patch that adjusts unaligned vector cost for
POWER8, which may affect this.  Because this PR depends on the cost model, this
may vary with processor.  Because of the change in cost model usage between 4.8
and 4.9, the code generation will change.  On the other hand, the vectorizer
tuning is encoding x86 preferences.

[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

[wschmidt at gcc dot gnu.org]

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

--- Comment #28 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
I agree with Richi's assessment that this isn't a regression because of the
change in default for cost modeling.

Once my patch lands after GCC 5 releases, and gets backported various places,
we will see much simpler code generation for POWER8 hardware and the
vectorization will succeed.  The cost model for unaligned loads and stores will
return 1 rather than the larger values as *most* of the time, unaligned
loads/stores will perform similarly to aligned ones on POWER8.  (Caveats at
page boundaries and so forth, but at the moment I've chosen to be optimistic.)

[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

[wschmidt at gcc dot gnu.org]

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

--- Comment #29 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #26)

> it makes sense.  Note that we seem to prefer optimized re-alignment loads
> over misaligned loads (even if double-word aligned) - the vectorizer is not
> set
> up to decide that based on costs (the misaligned load would cost 2 while
> the optimized re-aligned load costs 6 - two aligned loads (2), one vector
> stmt
> for mask compute (1) and one permute (3)).

My pending patch deals with this by having POWER8 pretend that it doesn't have
a re-alignment load capability, enabling misaligned loads/stores, and setting
the costs to reasonable values.

[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

[msebor at gcc dot gnu.org]

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

--- Comment #30 from Martin Sebor <msebor at gcc dot gnu.org> ---
In light of this discussion it seems as though it might be best to keep the
changes to the tests for this functionality to a minimum for now.  Unless
someone has a different suggestion I'll post an updated patch that just fixes
the wrong string in costmodel-bb-slp-9a.c and adds a test for the one
regression that Richard already fixed (referenced in comment #10).

[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

[rguenth at gcc dot gnu.org]

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

--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to David Edelsohn from comment #27)
> On the other hand, the vectorizer tuning is encoding x86 preferences.

Huh, the vectorizer tuning is specified by target hooks.  And initial
vectorizer tuning was solely for powerpc (likewise for the cost model).

[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

[dje at gcc dot gnu.org]

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."

[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

[rguenther at suse dot de]

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)?

[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

[msebor at gcc dot gnu.org]

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

--- Comment #34 from Martin Sebor <msebor at gcc dot gnu.org> ---
Author: msebor
Date: Fri Mar  6 18:43:24 2015
New Revision: 221248

URL: https://gcc.gnu.org/viewcvs?rev=221248&root=gcc&view=rev
Log:
2015-03-05  Martin Sebor  <msebor@redhat.com>

    * PR testsuite/63175
    * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c (main1): Move
    checking of results into main to prevent it from getting optimized
    away.
    * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c

[Bug testsuite/63175] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[law at redhat dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com
            Summary|[4.9/5 regression] FAIL:    |[4.9 regression] FAIL:
                   |gcc.dg/vect/costmodel/ppc/c |gcc.dg/vect/costmodel/ppc/c
                   |ostmodel-bb-slp-9a.c        |ostmodel-bb-slp-9a.c
                   |scan-tree-dump-times slp2"  |scan-tree-dump-times slp2"
                   |basic block vectorized      |basic block vectorized
                   |using SLP" 1                |using SLP" 1

--- Comment #35 from Jeffrey A. Law <law at redhat dot com> ---
Performance regression fixed by Richi.  Testsuite improvements by Martin.  Both
on the trunk only.  Trunk regression marker removed.

[Bug testsuite/63175] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[msebor at gcc dot gnu.org]

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

--- Comment #36 from Martin Sebor <msebor at gcc dot gnu.org> ---
Author: msebor
Date: Tue Mar 10 21:06:41 2015
New Revision: 221336

URL: https://gcc.gnu.org/viewcvs?rev=221336&root=gcc&view=rev
Log:
2015-03-10  Martin Sebor  <msebor@redhat.com>

    PR testsuite/63175
    * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c (main1): Move
    checking of results into main to prevent it from getting optimized
    away.
    * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: New test.


Added:
   
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c
Modified:
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
   
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c

[Bug testsuite/63175] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #37 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug testsuite/63175] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[msebor at gcc dot gnu.org]

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

--- Comment #38 from Martin Sebor <msebor at gcc dot gnu.org> ---
Author: msebor
Date: Mon Mar 23 17:37:25 2015
New Revision: 221601

URL: https://gcc.gnu.org/viewcvs?rev=221601&root=gcc&view=rev
Log:
2015-03-23  Martin Sebor  <msebor@redhat.com>

    PR testsuite/63175
    * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: Scan
    assembly for lvx in addition to lxv.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c

[Bug testsuite/63175] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1

[wschmidt at gcc dot gnu.org]

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

--- Comment #39 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Author: wschmidt
Date: Fri May 29 16:48:37 2015
New Revision: 223872

URL: https://gcc.gnu.org/viewcvs?rev=223872&root=gcc&view=rev
Log:
2015-05-29  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>

        Backported from mainline
        2015-03-23  Martin Sebor  <msebor@redhat.com>

        PR testsuite/63175
        * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: Scan
        assembly for lvx in addition to lxv.


Modified:
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
   
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c