| Message ID | 54F48FA2.9000908@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 03/02/15 09:28, Martin Sebor wrote: > On 03/02/2015 06:58 AM, Richard Biener wrote: >> On Fri, 27 Feb 2015, Martin Sebor wrote: >> >>>>> Given that Martin's fix to the testcase allowed it to succeed without >>>>> Richi's fix for the underlying problem, is there a modification to the >>>>> testcase or a new testcase that would really test the optimization? >>>> >>>> Let me work on it. >>> >>> Below is a patch with a couple of minor tweaks to the existing >>> test first to update the search string and second to better >>> exercise the vectorization not only when the source address >>> isn't aligned on the expected boundary but also when the >>> destination address isn't. This enhancement revealed >>> an outstanding aspect of the regression (not fixed by Richard's >>> already committed patch). >>> >>> Besides this change, the patch also adds a number of other >>> tests to better exercise the vectorization by verifying it >>> takes place for arrays of elements of other sizes besides >>> word: byte, half word, and double word. Those tests reveal >>> both another regression WRT 4.8 and further vectorization >>> opportunities not exploited even in 4.8. I marked the latter >>> XFAIL in the tests so that when the regression is fully >>> resolved, the tests should pass with no unexpected failures. >> >> I have a hard time applying the patch because of line-wrapping issues >> or my patch tool not groking the git diffs. >> >> Can you please either commit the patch or extract the testcase >> that still regresses and paste it into PR63175? > > I pasted a couple of such test cases to the bug. The full patch > is also attached to this email in case there was a problem with > line wrapping. So for the unaligned case, is that really a regression when compared to earlier compilers? If not, then it seems that we ought to at least be at a point where the regression marker for that BZ can be removed, right? ie, Richi's patch fixed the actual code quality regression and your patch fixes the testsuite aspects, right? jeff
On 03/06/2015 10:28 AM, Jeff Law wrote: > On 03/02/15 09:28, Martin Sebor wrote: >> On 03/02/2015 06:58 AM, Richard Biener wrote: >>> On Fri, 27 Feb 2015, Martin Sebor wrote: >>> >>>>>> Given that Martin's fix to the testcase allowed it to succeed without >>>>>> Richi's fix for the underlying problem, is there a modification to >>>>>> the >>>>>> testcase or a new testcase that would really test the optimization? >>>>> >>>>> Let me work on it. >>>> >>>> Below is a patch with a couple of minor tweaks to the existing >>>> test first to update the search string and second to better >>>> exercise the vectorization not only when the source address >>>> isn't aligned on the expected boundary but also when the >>>> destination address isn't. This enhancement revealed >>>> an outstanding aspect of the regression (not fixed by Richard's >>>> already committed patch). >>>> >>>> Besides this change, the patch also adds a number of other >>>> tests to better exercise the vectorization by verifying it >>>> takes place for arrays of elements of other sizes besides >>>> word: byte, half word, and double word. Those tests reveal >>>> both another regression WRT 4.8 and further vectorization >>>> opportunities not exploited even in 4.8. I marked the latter >>>> XFAIL in the tests so that when the regression is fully >>>> resolved, the tests should pass with no unexpected failures. >>> >>> I have a hard time applying the patch because of line-wrapping issues >>> or my patch tool not groking the git diffs. >>> >>> Can you please either commit the patch or extract the testcase >>> that still regresses and paste it into PR63175? >> >> I pasted a couple of such test cases to the bug. The full patch >> is also attached to this email in case there was a problem with >> line wrapping. > So for the unaligned case, is that really a regression when compared to > earlier compilers? If not, then it seems that we ought to at least be > at a point where the regression marker for that BZ can be removed, > right? ie, Richi's patch fixed the actual code quality regression and > your patch fixes the testsuite aspects, right? My interpretation of the bug report is that it points out two problems: 1) a failure in the costmodel-bb-slp-9a.c test 2) a quality regression observed by inspecting the assembly emitted for the test The two are unrelated in that (2) didn't cause (1). Since Richi's patch fixed (2) and my latest patch fixes (1) I would be inclined to consider the bug resolved. While GCC 5 doesn't vectorize some code that 4.8 does with the same options, it's apparently by accident (or due to a bug in 4.8). Since 5.0 does vectorize the same code when the right set of options is specified, I agree with others that none of my additional tests has exposed any other regressions than the one that's already been addressed. Martin
On March 6, 2015 9:22:05 PM CET, Martin Sebor <msebor@redhat.com> wrote: >On 03/06/2015 10:28 AM, Jeff Law wrote: >> On 03/02/15 09:28, Martin Sebor wrote: >>> On 03/02/2015 06:58 AM, Richard Biener wrote: >>>> On Fri, 27 Feb 2015, Martin Sebor wrote: >>>> >>>>>>> Given that Martin's fix to the testcase allowed it to succeed >without >>>>>>> Richi's fix for the underlying problem, is there a modification >to >>>>>>> the >>>>>>> testcase or a new testcase that would really test the >optimization? >>>>>> >>>>>> Let me work on it. >>>>> >>>>> Below is a patch with a couple of minor tweaks to the existing >>>>> test first to update the search string and second to better >>>>> exercise the vectorization not only when the source address >>>>> isn't aligned on the expected boundary but also when the >>>>> destination address isn't. This enhancement revealed >>>>> an outstanding aspect of the regression (not fixed by Richard's >>>>> already committed patch). >>>>> >>>>> Besides this change, the patch also adds a number of other >>>>> tests to better exercise the vectorization by verifying it >>>>> takes place for arrays of elements of other sizes besides >>>>> word: byte, half word, and double word. Those tests reveal >>>>> both another regression WRT 4.8 and further vectorization >>>>> opportunities not exploited even in 4.8. I marked the latter >>>>> XFAIL in the tests so that when the regression is fully >>>>> resolved, the tests should pass with no unexpected failures. >>>> >>>> I have a hard time applying the patch because of line-wrapping >issues >>>> or my patch tool not groking the git diffs. >>>> >>>> Can you please either commit the patch or extract the testcase >>>> that still regresses and paste it into PR63175? >>> >>> I pasted a couple of such test cases to the bug. The full patch >>> is also attached to this email in case there was a problem with >>> line wrapping. >> So for the unaligned case, is that really a regression when compared >to >> earlier compilers? If not, then it seems that we ought to at least >be >> at a point where the regression marker for that BZ can be removed, >> right? ie, Richi's patch fixed the actual code quality regression >and >> your patch fixes the testsuite aspects, right? > >My interpretation of the bug report is that it points out >two problems: > >1) a failure in the costmodel-bb-slp-9a.c test >2) a quality regression observed by inspecting the assembly > emitted for the test > >The two are unrelated in that (2) didn't cause (1). > >Since Richi's patch fixed (2) and my latest patch fixes (1) >I would be inclined to consider the bug resolved. > >While GCC 5 doesn't vectorize some code that 4.8 does with >the same options, it's apparently by accident (or due to >a bug in 4.8). Since 5.0 does vectorize the same code when >the right set of options is specified, I agree with others >that none of my additional tests has exposed any other >regressions than the one that's already been addressed. Yes. Once the test cases have been fixed we should close the bug as fixed. Richard. >Martin
On 03/07/15 01:34, Richard Biener wrote: > On March 6, 2015 9:22:05 PM CET, Martin Sebor <msebor@redhat.com> wrote: >> On 03/06/2015 10:28 AM, Jeff Law wrote: >>> On 03/02/15 09:28, Martin Sebor wrote: >>>> On 03/02/2015 06:58 AM, Richard Biener wrote: >>>>> On Fri, 27 Feb 2015, Martin Sebor wrote: >>>>> >>>>>>>> Given that Martin's fix to the testcase allowed it to succeed >> without >>>>>>>> Richi's fix for the underlying problem, is there a modification >> to >>>>>>>> the >>>>>>>> testcase or a new testcase that would really test the >> optimization? >>>>>>> >>>>>>> Let me work on it. >>>>>> >>>>>> Below is a patch with a couple of minor tweaks to the existing >>>>>> test first to update the search string and second to better >>>>>> exercise the vectorization not only when the source address >>>>>> isn't aligned on the expected boundary but also when the >>>>>> destination address isn't. This enhancement revealed >>>>>> an outstanding aspect of the regression (not fixed by Richard's >>>>>> already committed patch). >>>>>> >>>>>> Besides this change, the patch also adds a number of other >>>>>> tests to better exercise the vectorization by verifying it >>>>>> takes place for arrays of elements of other sizes besides >>>>>> word: byte, half word, and double word. Those tests reveal >>>>>> both another regression WRT 4.8 and further vectorization >>>>>> opportunities not exploited even in 4.8. I marked the latter >>>>>> XFAIL in the tests so that when the regression is fully >>>>>> resolved, the tests should pass with no unexpected failures. >>>>> >>>>> I have a hard time applying the patch because of line-wrapping >> issues >>>>> or my patch tool not groking the git diffs. >>>>> >>>>> Can you please either commit the patch or extract the testcase >>>>> that still regresses and paste it into PR63175? >>>> >>>> I pasted a couple of such test cases to the bug. The full patch >>>> is also attached to this email in case there was a problem with >>>> line wrapping. >>> So for the unaligned case, is that really a regression when compared >> to >>> earlier compilers? If not, then it seems that we ought to at least >> be >>> at a point where the regression marker for that BZ can be removed, >>> right? ie, Richi's patch fixed the actual code quality regression >> and >>> your patch fixes the testsuite aspects, right? >> >> My interpretation of the bug report is that it points out >> two problems: >> >> 1) a failure in the costmodel-bb-slp-9a.c test >> 2) a quality regression observed by inspecting the assembly >> emitted for the test >> >> The two are unrelated in that (2) didn't cause (1). >> >> Since Richi's patch fixed (2) and my latest patch fixes (1) >> I would be inclined to consider the bug resolved. >> >> While GCC 5 doesn't vectorize some code that 4.8 does with >> the same options, it's apparently by accident (or due to >> a bug in 4.8). Since 5.0 does vectorize the same code when >> the right set of options is specified, I agree with others >> that none of my additional tests has exposed any other >> regressions than the one that's already been addressed. > > Yes. Once the test cases have been fixed we should close the bug as fixed. Trunk regression marker removed. Not sure if it is worth backporting to 4.9, but I left the 4.9 regression marker and the BZ open just in case. jeff
On March 7, 2015 5:20:08 PM CET, Jeff Law <law@redhat.com> wrote: >On 03/07/15 01:34, Richard Biener wrote: >> On March 6, 2015 9:22:05 PM CET, Martin Sebor <msebor@redhat.com> >wrote: >>> On 03/06/2015 10:28 AM, Jeff Law wrote: >>>> On 03/02/15 09:28, Martin Sebor wrote: >>>>> On 03/02/2015 06:58 AM, Richard Biener wrote: >>>>>> On Fri, 27 Feb 2015, Martin Sebor wrote: >>>>>> >>>>>>>>> Given that Martin's fix to the testcase allowed it to succeed >>> without >>>>>>>>> Richi's fix for the underlying problem, is there a >modification >>> to >>>>>>>>> the >>>>>>>>> testcase or a new testcase that would really test the >>> optimization? >>>>>>>> >>>>>>>> Let me work on it. >>>>>>> >>>>>>> Below is a patch with a couple of minor tweaks to the existing >>>>>>> test first to update the search string and second to better >>>>>>> exercise the vectorization not only when the source address >>>>>>> isn't aligned on the expected boundary but also when the >>>>>>> destination address isn't. This enhancement revealed >>>>>>> an outstanding aspect of the regression (not fixed by Richard's >>>>>>> already committed patch). >>>>>>> >>>>>>> Besides this change, the patch also adds a number of other >>>>>>> tests to better exercise the vectorization by verifying it >>>>>>> takes place for arrays of elements of other sizes besides >>>>>>> word: byte, half word, and double word. Those tests reveal >>>>>>> both another regression WRT 4.8 and further vectorization >>>>>>> opportunities not exploited even in 4.8. I marked the latter >>>>>>> XFAIL in the tests so that when the regression is fully >>>>>>> resolved, the tests should pass with no unexpected failures. >>>>>> >>>>>> I have a hard time applying the patch because of line-wrapping >>> issues >>>>>> or my patch tool not groking the git diffs. >>>>>> >>>>>> Can you please either commit the patch or extract the testcase >>>>>> that still regresses and paste it into PR63175? >>>>> >>>>> I pasted a couple of such test cases to the bug. The full patch >>>>> is also attached to this email in case there was a problem with >>>>> line wrapping. >>>> So for the unaligned case, is that really a regression when >compared >>> to >>>> earlier compilers? If not, then it seems that we ought to at >least >>> be >>>> at a point where the regression marker for that BZ can be removed, >>>> right? ie, Richi's patch fixed the actual code quality regression >>> and >>>> your patch fixes the testsuite aspects, right? >>> >>> My interpretation of the bug report is that it points out >>> two problems: >>> >>> 1) a failure in the costmodel-bb-slp-9a.c test >>> 2) a quality regression observed by inspecting the assembly >>> emitted for the test >>> >>> The two are unrelated in that (2) didn't cause (1). >>> >>> Since Richi's patch fixed (2) and my latest patch fixes (1) >>> I would be inclined to consider the bug resolved. >>> >>> While GCC 5 doesn't vectorize some code that 4.8 does with >>> the same options, it's apparently by accident (or due to >>> a bug in 4.8). Since 5.0 does vectorize the same code when >>> the right set of options is specified, I agree with others >>> that none of my additional tests has exposed any other >>> regressions than the one that's already been addressed. >> >> Yes. Once the test cases have been fixed we should close the bug as >fixed. >Trunk regression marker removed. Not sure if it is worth backporting >to >4.9, but I left the 4.9 regression marker and the BZ open just in case. I backported the fix to the 4.9 branch already, so it would be nice to get the test cases fixes there as well. Richard. >jeff
On 03/08/15 03:14, Richard Biener wrote: > On March 7, 2015 5:20:08 PM CET, Jeff Law <law@redhat.com> wrote: >> On 03/07/15 01:34, Richard Biener wrote: >>> On March 6, 2015 9:22:05 PM CET, Martin Sebor <msebor@redhat.com> >> wrote: >>>> On 03/06/2015 10:28 AM, Jeff Law wrote: >>>>> On 03/02/15 09:28, Martin Sebor wrote: >>>>>> On 03/02/2015 06:58 AM, Richard Biener wrote: >>>>>>> On Fri, 27 Feb 2015, Martin Sebor wrote: >>>>>>> >>>>>>>>>> Given that Martin's fix to the testcase allowed it to succeed >>>> without >>>>>>>>>> Richi's fix for the underlying problem, is there a >> modification >>>> to >>>>>>>>>> the >>>>>>>>>> testcase or a new testcase that would really test the >>>> optimization? >>>>>>>>> >>>>>>>>> Let me work on it. >>>>>>>> >>>>>>>> Below is a patch with a couple of minor tweaks to the existing >>>>>>>> test first to update the search string and second to better >>>>>>>> exercise the vectorization not only when the source address >>>>>>>> isn't aligned on the expected boundary but also when the >>>>>>>> destination address isn't. This enhancement revealed >>>>>>>> an outstanding aspect of the regression (not fixed by Richard's >>>>>>>> already committed patch). >>>>>>>> >>>>>>>> Besides this change, the patch also adds a number of other >>>>>>>> tests to better exercise the vectorization by verifying it >>>>>>>> takes place for arrays of elements of other sizes besides >>>>>>>> word: byte, half word, and double word. Those tests reveal >>>>>>>> both another regression WRT 4.8 and further vectorization >>>>>>>> opportunities not exploited even in 4.8. I marked the latter >>>>>>>> XFAIL in the tests so that when the regression is fully >>>>>>>> resolved, the tests should pass with no unexpected failures. >>>>>>> >>>>>>> I have a hard time applying the patch because of line-wrapping >>>> issues >>>>>>> or my patch tool not groking the git diffs. >>>>>>> >>>>>>> Can you please either commit the patch or extract the testcase >>>>>>> that still regresses and paste it into PR63175? >>>>>> >>>>>> I pasted a couple of such test cases to the bug. The full patch >>>>>> is also attached to this email in case there was a problem with >>>>>> line wrapping. >>>>> So for the unaligned case, is that really a regression when >> compared >>>> to >>>>> earlier compilers? If not, then it seems that we ought to at >> least >>>> be >>>>> at a point where the regression marker for that BZ can be removed, >>>>> right? ie, Richi's patch fixed the actual code quality regression >>>> and >>>>> your patch fixes the testsuite aspects, right? >>>> >>>> My interpretation of the bug report is that it points out >>>> two problems: >>>> >>>> 1) a failure in the costmodel-bb-slp-9a.c test >>>> 2) a quality regression observed by inspecting the assembly >>>> emitted for the test >>>> >>>> The two are unrelated in that (2) didn't cause (1). >>>> >>>> Since Richi's patch fixed (2) and my latest patch fixes (1) >>>> I would be inclined to consider the bug resolved. >>>> >>>> While GCC 5 doesn't vectorize some code that 4.8 does with >>>> the same options, it's apparently by accident (or due to >>>> a bug in 4.8). Since 5.0 does vectorize the same code when >>>> the right set of options is specified, I agree with others >>>> that none of my additional tests has exposed any other >>>> regressions than the one that's already been addressed. >>> >>> Yes. Once the test cases have been fixed we should close the bug as >> fixed. >> Trunk regression marker removed. Not sure if it is worth backporting >> to >> 4.9, but I left the 4.9 regression marker and the BZ open just in case. > > I backported the fix to the 4.9 branch already, so it would be nice to get the test cases fixes there as well. Martin -- that's your cue ;-) jeff
>> I backported the fix to the 4.9 branch already, so it would be nice to >> get the test cases fixes there as well. > Martin -- that's your cue ;-) Sure. It's on my list of things to do. Martin
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog index cc86e37..4edd559 100644 --- a/gcc/testsuite/ChangeLog +++ b/gcc/testsuite/ChangeLog @@ -1,3 +1,15 @@ +2015-02-27 Martin Sebor <msebor@redhat.com> + + PR testsuite/63175 + * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c (main1): Rename... + (copy_to_unaligned): ...to this and move checking of results into + main. + (copy_from_unaligned): New function. + * costmodel-bb-slp-pr63175-base.c: New test. + * costmodel-bb-slp-pr63175-dword.c: New test. + * costmodel-bb-slp-pr63175-hword.c: New test. + * costmodel-bb-slp-pr63175-word.c: New test. + 2015-02-27 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/65048 diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c index e1bc1a8..a2dc367 100644 --- a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c +++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c @@ -1,46 +1,63 @@ /* { dg-require-effective-target vect_int } */ -#include <stdarg.h> #include "../../tree-vect.h" #define N 16 unsigned int out[N]; -unsigned int in[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}; +const unsigned int in[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}; -__attribute__ ((noinline)) int -main1 (unsigned int x, unsigned int y) +__attribute__ ((noinline)) void +copy_to_unaligned (void) { - int i; - unsigned int *pin = &in[1]; + const unsigned int *pin = &in[1]; unsigned int *pout = &out[0]; - unsigned int a0, a1, a2, a3; /* Misaligned load. */ *pout++ = *pin++; *pout++ = *pin++; *pout++ = *pin++; *pout++ = *pin++; +} - /* Check results. */ - if (out[0] != in[1] - || out[1] != in[2] - || out[2] != in[3] - || out[3] != in[4]) - abort(); +__attribute__ ((noinline)) void +copy_from_unaligned (void) +{ + const unsigned int *pin = &in[0]; + unsigned int *pout = &out[1]; - return 0; + /* Misaligned load. */ + *pout++ = *pin++; + *pout++ = *pin++; + *pout++ = *pin++; + *pout++ = *pin++; } int main (void) { check_vect (); - main1 (2, 3); + copy_to_unaligned (); + + /* Check results outside of main1 where it would likely + be optimized away. */ + if (out[0] != in[1] + || out[1] != in[2] + || out[2] != in[3] + || out[3] != in[4]) + abort(); + + copy_from_unaligned (); + + if (out[1] != in[0] + || out[2] != in[1] + || out[3] != in[2] + || out[4] != in[3]) + abort(); return 0; } -/* { dg-final { scan-tree-dump-times "basic block vectorized using SLP" 1 "slp2" { xfail vect_no_align } } } */ +/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" { xfail vect_no_align } } } */ /* { dg-final { cleanup-tree-dump "slp2" } } */ diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-base.c b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-base.c new file mode 100644 index 0000000..b94cf0e --- /dev/null +++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-base.c @@ -0,0 +1,45 @@ +/* { dg-require-effective-target vect_int } */ +/* { dg-do compile } */ + +#define DEFINE_DATA(T) \ + const T T ## _ ## src[] = { \ + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\ + 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32 }; \ + T T ## _ ## dst[sizeof T ## _ ## src / sizeof (T)] + +#define DEFINE_COPY_M_N(T, srcoff, dstoff) \ +void copy_ ## T ## _ ## srcoff ## _ ## dstoff (void) { \ + const T *s = T ## _ ## src + srcoff; \ + T *d = T ## _ ## dst + dstoff; \ + unsigned i; \ + for (i = 0; i != 16 / sizeof *s; ++i) \ + *d++ = *s++; \ +} + +#define DEFINE_COPY_M(T, M) \ + DEFINE_COPY_M_N (T, M, 0); \ + DEFINE_COPY_M_N (T, M, 1); \ + DEFINE_COPY_M_N (T, M, 2); \ + DEFINE_COPY_M_N (T, M, 3) + +#define TEST_COPY(T) \ + DEFINE_DATA (T); \ + DEFINE_COPY_M (T, 0); \ + DEFINE_COPY_M (T, 1); \ + DEFINE_COPY_M (T, 2); \ + DEFINE_COPY_M (T, 3) + +#ifndef Type +# define Type char +#endif + +TEST_COPY (Type); + +/* Verify that the assembly contains vector instructions alone + with no byte loads (lb, lbu, lbz, lbzu, or their indexed forms) + or byte stores (stb, stbu, stbx, stbux, or their indexed + forms). */ + +/* { dg-final { scan-assembler "\t\(lxv|lvsr|stxv\)" } } */ +/* { dg-final { scan-assembler-not "\tlbz?u?x? " { xfail *-*-* } } } */ +/* { dg-final { scan-assembler-not "\tstbu?x? " { xfail *-*-* } } } */ diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-dword.c b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-dword.c new file mode 100644 index 0000000..87d5cb6 --- /dev/null +++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-dword.c @@ -0,0 +1,13 @@ +/* { dg-require-effective-target vect_int } */ +/* { dg-do compile } */ + +#define Type long +#include "costmodel-bb-slp-pr63175-base.c" + +/* Verify that the assembly contains vector instructions alone + with no doubleword loads (ld, ldu, or their indexed forms) + or stores (std, stdu, or their indexed forms). */ + +/* { dg-final { scan-assembler "\t\(lxv|lvsr|stxv\)" } } */ +/* { dg-final { scan-assembler-not "\tldu?x? " } } */ +/* { dg-final { scan-assembler-not "\tstdu?x? " } } */ diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-hword.c b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-hword.c new file mode 100644 index 0000000..8c22294 --- /dev/null +++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-hword.c @@ -0,0 +1,13 @@ +/* { dg-require-effective-target vect_int } */ +/* { dg-do compile } */ + +#define Type short +#include "costmodel-bb-slp-pr63175-base.c" + +/* Verify that the assembly contains vector instructions alone + with no halfword loads (lh, lhz, lhzu or their indexed forms) + or halfword stores (sth, sthu, or their indexed forms). */ + +/* { dg-final { scan-assembler "\t\(lxv|lvsr|stxv\)" } } */ +/* { dg-final { scan-assembler-not "\tlhz?u?x? " { xfail *-*-* } } } */ +/* { dg-final { scan-assembler-not "\tsthu?x? " { xfail *-*-* } } } */ diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-word.c b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-word.c new file mode 100644 index 0000000..942b8a6 --- /dev/null +++ b/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-pr63175-word.c @@ -0,0 +1,13 @@ +/* { dg-require-effective-target vect_int } */ +/* { dg-do compile } */ + +#define Type int +#include "costmodel-bb-slp-pr63175-base.c" + +/* Verify that the assembly contains vector instructions alone + with no word loads (lw, lwz, lwzu or their indexed forms + or word stores (stw or stwu, or their indexed forms). */ + +/* { dg-final { scan-assembler "\t\(lxv|lvsr|stxv\)" } } */ +/* { dg-final { scan-assembler-not "\tlwz?u?x? " } } */ +/* { dg-final { scan-assembler-not "\tstwu?x? " } } */