| Message ID | 1536355654.5318.14.camel@brimstone.rchland.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | [rs6000] fix PR86952 (p8-vec-xl-*.c tests) | expand |
Hi! On Fri, Sep 07, 2018 at 04:27:34PM -0500, Will Schmidt wrote: > The expected instructions for this test (p8-vec-xl-*) were incorrect for some > of the power targets. Add codegen variations as appropriate for > the targeted platform. > pr86952/testsuite I think you need to write this as PR (i.e. caps) followed by a space, and the component of this bug is "target" in bugzilla (which is better here), and the number is 86592. So: PR target/86592 and it will automagically add a comment to the right bug :-) > -/* { dg-final { scan-assembler-times "lvx" 4 } } */ > -/* { dg-final { scan-assembler-times "stvx" 4 } } */ > -/* { dg-final { scan-assembler-times "xxpermdi" 0 } } */ > +/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M} 4 } } */ > +/* { dg-final { scan-assembler-times {\mstvx\M|\mstxvd2x\M} 4 } } */ So you get xxpermdi when {l,st}xvd2x is generated? What platform is that on? Is that the correct code to generate, or is this a regression? Is this the difference between LE and BE code generation? So many questions, I am sorry :-) Segher
On Fri, 2018-09-07 at 16:54 -0500, Segher Boessenkool wrote: > Hi! > > On Fri, Sep 07, 2018 at 04:27:34PM -0500, Will Schmidt wrote: > > The expected instructions for this test (p8-vec-xl-*) were incorrect for some > > of the power targets. Add codegen variations as appropriate for > > the targeted platform. > > > pr86952/testsuite > > I think you need to write this as PR (i.e. caps) followed by a space, > and the component of this bug is "target" in bugzilla (which is better > here), and the number is 86592. So: > > PR target/86592 > > and it will automagically add a comment to the right bug :-) aah, yes, my bad. thanks. > > > -/* { dg-final { scan-assembler-times "lvx" 4 } } */ > > -/* { dg-final { scan-assembler-times "stvx" 4 } } */ > > -/* { dg-final { scan-assembler-times "xxpermdi" 0 } } */ > > +/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M} 4 } } */ > > +/* { dg-final { scan-assembler-times {\mstvx\M|\mstxvd2x\M} 4 } } */ > > So you get xxpermdi when {l,st}xvd2x is generated? What platform is that > on? Is that the correct code to generate, or is this a regression? Is > this the difference between LE and BE code generation? So many questions, > I am sorry :-) Hi, No prob, thanks for the question. :-) The -v2 test is new-ish, I added it when the gimple-folding for the vec_xst,vec_xl intrinsics went in since i was seeing some codegen variations at the time. The check for the lvx,stvx instructions is valid IF the test is built for a power9 target. The test actually specifies -mcpu=power8 in it's options, so it needs to handle the lxvd2x +xxpermdi and xxpermdi+stxvd2 instruction pairs as appropriate for that processor. > Segher >
Hi again, On Tue, Sep 11, 2018 at 10:04:45AM -0500, Will Schmidt wrote: > On Fri, 2018-09-07 at 16:54 -0500, Segher Boessenkool wrote: > > On Fri, Sep 07, 2018 at 04:27:34PM -0500, Will Schmidt wrote: > > > -/* { dg-final { scan-assembler-times "lvx" 4 } } */ > > > -/* { dg-final { scan-assembler-times "stvx" 4 } } */ > > > -/* { dg-final { scan-assembler-times "xxpermdi" 0 } } */ > > > +/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M} 4 } } */ > > > +/* { dg-final { scan-assembler-times {\mstvx\M|\mstxvd2x\M} 4 } } */ > > > > So you get xxpermdi when {l,st}xvd2x is generated? What platform is that > > on? Is that the correct code to generate, or is this a regression? Is > > this the difference between LE and BE code generation? So many questions, > > I am sorry :-) > > Hi, > No prob, thanks for the question. :-) > > The -v2 test is new-ish, I added it when the gimple-folding for the > vec_xst,vec_xl intrinsics went in since i was seeing some codegen > variations at the time. The check for the lvx,stvx instructions is > valid IF the test is built for a power9 target. The test actually > specifies -mcpu=power8 in it's options, so it needs to handle the lxvd2x > +xxpermdi and xxpermdi+stxvd2 instruction pairs as appropriate for that > processor. lvx is the old AltiVec instruction, that uses (A+B)&-16 as address for lvx D,A,B . The instruction new on power9 is lxv, which does reg+imm (instead of reg+reg) addressing. Maybe the expected result should be separated between BE and LE, or similar. Segher
On Tue, 2018-09-11 at 13:20 -0500, Segher Boessenkool wrote: > Hi again, > > On Tue, Sep 11, 2018 at 10:04:45AM -0500, Will Schmidt wrote: > > On Fri, 2018-09-07 at 16:54 -0500, Segher Boessenkool wrote: > > > On Fri, Sep 07, 2018 at 04:27:34PM -0500, Will Schmidt wrote: > > > > -/* { dg-final { scan-assembler-times "lvx" 4 } } */ > > > > -/* { dg-final { scan-assembler-times "stvx" 4 } } */ > > > > -/* { dg-final { scan-assembler-times "xxpermdi" 0 } } */ > > > > +/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M} 4 } } */ > > > > +/* { dg-final { scan-assembler-times {\mstvx\M|\mstxvd2x\M} 4 } } */ > > > > > > So you get xxpermdi when {l,st}xvd2x is generated? What platform is that > > > on? Is that the correct code to generate, or is this a regression? Is > > > this the difference between LE and BE code generation? So many questions, > > > I am sorry :-) > > > > Hi, > > No prob, thanks for the question. :-) > > > > The -v2 test is new-ish, I added it when the gimple-folding for the > > vec_xst,vec_xl intrinsics went in since i was seeing some codegen > > variations at the time. The check for the lvx,stvx instructions is > > valid IF the test is built for a power9 target. The test actually > > specifies -mcpu=power8 in it's options, so it needs to handle the lxvd2x > > +xxpermdi and xxpermdi+stxvd2 instruction pairs as appropriate for that > > processor. > lvx is the old AltiVec instruction, that uses (A+B)&-16 as address > for lvx D,A,B . The instruction new on power9 is lxv, which does > reg+imm (instead of reg+reg) addressing. > > Maybe the expected result should be separated between BE and LE, or > similar. ok, I need to correct my earlier statement above. The visual similarity with lvx and lxv are obviously causing me trouble. The lxv showed up if built for power7. lvx showed up if built for power9. Digression - I do typically do a make check, then post-process re-run the tests I am working with while updating the -mcpu=power* options to cover across the power6,7,8,9 spectrum, and sift through those results. That is where and why the lvx,lxv bits got introduced. For the upstream test, which is "target {le}" and "-mcpu=power8" and has "do not override -mcpu=power8" stanzas, the simpler /* { dg-final { scan-assembler-times "lxvd2x" 4 } } */ /* { dg-final { scan-assembler-times "stxvd2x" 4 } } */ is sufficient. thanks, -Will > > > Segher >
diff --git a/gcc/testsuite/gcc.target/powerpc/p8-vec-xl-xst-v2.c b/gcc/testsuite/gcc.target/powerpc/p8-vec-xl-xst-v2.c index cc68ceb..7327af7 100644 --- a/gcc/testsuite/gcc.target/powerpc/p8-vec-xl-xst-v2.c +++ b/gcc/testsuite/gcc.target/powerpc/p8-vec-xl-xst-v2.c @@ -57,8 +57,7 @@ void bartle (vector unsigned short x, unsigned short * address) { vec_xst (x, 0, address); } -/* { dg-final { scan-assembler-times "lvx" 4 } } */ -/* { dg-final { scan-assembler-times "stvx" 4 } } */ -/* { dg-final { scan-assembler-times "xxpermdi" 0 } } */ +/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M} 4 } } */ +/* { dg-final { scan-assembler-times {\mstvx\M|\mstxvd2x\M} 4 } } */
Hi, The expected instructions for this test (p8-vec-xl-*) were incorrect for some of the power targets. Add codegen variations as appropriate for the targeted platform. Tested across power platforms. This appears to now run clean. OK for trunk? Thanks -Will [testsuite] 2018-09-06 Will Schmidt <will_schmidt@vnet.ibm.com> pr86952/testsuite * p8-vec-xl-xst-v2.c: Add and update expected codegen.