testsuite: Fix up pr111754.c test
Checks
Commit Message
On Tue, Nov 28, 2023 at 09:43:52AM +0100, Jakub Jelinek wrote:
> On Tue, Nov 28, 2023 at 03:56:47PM +0800, juzhe.zhong@rivai.ai wrote:
> > Hi, there is a regression in RISC-V caused by this patch:
> >
> > FAIL: gcc.dg/vect/pr111754.c -flto -ffat-lto-objects scan-tree-dump optimized "return { 0.0, 9.0e\\+0, 0.0, 0.0 }"
> > FAIL: gcc.dg/vect/pr111754.c scan-tree-dump optimized "return { 0.0, 9.0e\\+0, 0.0, 0.0 }"
> >
> > I have checked the dump is :
> > F foo (F a, F b)
> > {
> > <bb 2> [local count: 1073741824]:
> > <retval> = { 0.0, 9.0e+0, 0.0, 0.0 };
> > return <retval>;
> >
> > }
> >
> > The dump IR seems reasonable to me.
> > I wonder whether we should walk around in RISC-V backend to generate the same IR as ARM SVE ?
> > Or we should adjust the test ?
>
> Note, the test also FAILs on i686-linux (but not e.g. on x86_64-linux):
> /home/jakub/src/gcc/obj67/gcc/xgcc -B/home/jakub/src/gcc/obj67/gcc/ /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c -fdiagnostics-plain-output -O2 -fdump-tree-optimized -S -o pr111754.s
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c: In function 'foo':
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:7:1: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:6:3: note: the ABI for passing parameters with 16-byte alignment has changed in GCC 4.6
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:6:3: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi]
> FAIL: gcc.dg/vect/pr111754.c (test for excess errors)
> Excess errors:
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:7:1: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:6:3: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi]
>
> PASS: gcc.dg/vect/pr111754.c scan-tree-dump-not optimized "VEC_PERM_EXPR"
> FAIL: gcc.dg/vect/pr111754.c scan-tree-dump optimized "return { 0.0, 9.0e\\+0, 0.0, 0.0 }"
>
> So, I think it is wrong to specify
> /* { dg-options "-O2 -fdump-tree-optimized" } */
> in the test, should be dg-additional-options instead, so that it gets
> the implied vector compilation options e.g. for i686-linux (-msse2 in that
> case at least), question is if -Wno-psabi should be added as well or not,
> and certainly the scan-tree-dump needs to be guarded by appropriate
> vect_* effective target (but dunno which, one which asserts support for
> V4SFmode and returning it).
> Alternatively, perhaps don't check optimized dump but some earlier one
> before generic vector lowering, then hopefully it could match on all
> targets? Maybe with the <retval> = ... vs. return ... variants.
All in one patch now.
Tested on x86_64-linux with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-mno-sse,-m64\} vect.exp=pr111754.c'
Ok for trunk?
2023-11-28 Jakub Jelinek <jakub@redhat.com>
PR middle-end/111754
* gcc.dg/vect/pr111754.c: Use dg-additional-options rather than
dg-options, add -Wno-psabi and use -fdump-tree-forwprop1 rather than
-fdump-tree-optimized. Scan forwprop1 dump rather than optimized and
scan for either direct return or setting of <retval> to the vector.
Jakub
Comments
> Am 28.11.2023 um 09:58 schrieb Jakub Jelinek <jakub@redhat.com>:
>
> On Tue, Nov 28, 2023 at 09:43:52AM +0100, Jakub Jelinek wrote:
>>> On Tue, Nov 28, 2023 at 03:56:47PM +0800, juzhe.zhong@rivai.ai wrote:
>>> Hi, there is a regression in RISC-V caused by this patch:
>>>
>>> FAIL: gcc.dg/vect/pr111754.c -flto -ffat-lto-objects scan-tree-dump optimized "return { 0.0, 9.0e\\+0, 0.0, 0.0 }"
>>> FAIL: gcc.dg/vect/pr111754.c scan-tree-dump optimized "return { 0.0, 9.0e\\+0, 0.0, 0.0 }"
>>>
>>> I have checked the dump is :
>>> F foo (F a, F b)
>>> {
>>> <bb 2> [local count: 1073741824]:
>>> <retval> = { 0.0, 9.0e+0, 0.0, 0.0 };
>>> return <retval>;
>>>
>>> }
>>>
>>> The dump IR seems reasonable to me.
>>> I wonder whether we should walk around in RISC-V backend to generate the same IR as ARM SVE ?
>>> Or we should adjust the test ?
>>
>> Note, the test also FAILs on i686-linux (but not e.g. on x86_64-linux):
>> /home/jakub/src/gcc/obj67/gcc/xgcc -B/home/jakub/src/gcc/obj67/gcc/ /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c -fdiagnostics-plain-output -O2 -fdump-tree-optimized -S -o pr111754.s
>> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c: In function 'foo':
>> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:7:1: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
>> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:6:3: note: the ABI for passing parameters with 16-byte alignment has changed in GCC 4.6
>> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:6:3: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi]
>> FAIL: gcc.dg/vect/pr111754.c (test for excess errors)
>> Excess errors:
>> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:7:1: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
>> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:6:3: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi]
>>
>> PASS: gcc.dg/vect/pr111754.c scan-tree-dump-not optimized "VEC_PERM_EXPR"
>> FAIL: gcc.dg/vect/pr111754.c scan-tree-dump optimized "return { 0.0, 9.0e\\+0, 0.0, 0.0 }"
>>
>> So, I think it is wrong to specify
>> /* { dg-options "-O2 -fdump-tree-optimized" } */
>> in the test, should be dg-additional-options instead, so that it gets
>> the implied vector compilation options e.g. for i686-linux (-msse2 in that
>> case at least), question is if -Wno-psabi should be added as well or not,
>> and certainly the scan-tree-dump needs to be guarded by appropriate
>> vect_* effective target (but dunno which, one which asserts support for
>> V4SFmode and returning it).
>> Alternatively, perhaps don't check optimized dump but some earlier one
>> before generic vector lowering, then hopefully it could match on all
>> targets? Maybe with the <retval> = ... vs. return ... variants.
>
> All in one patch now.
>
> Tested on x86_64-linux with
> make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-mno-sse,-m64\} vect.exp=pr111754.c'
> Ok for trunk?
Ok
Richard
> 2023-11-28 Jakub Jelinek <jakub@redhat.com>
>
> PR middle-end/111754
> * gcc.dg/vect/pr111754.c: Use dg-additional-options rather than
> dg-options, add -Wno-psabi and use -fdump-tree-forwprop1 rather than
> -fdump-tree-optimized. Scan forwprop1 dump rather than optimized and
> scan for either direct return or setting of <retval> to the vector.
>
> --- gcc/testsuite/gcc.dg/vect/pr111754.c.jj 2023-11-28 08:46:28.422801989 +0100
> +++ gcc/testsuite/gcc.dg/vect/pr111754.c 2023-11-28 09:52:56.761059292 +0100
> @@ -1,5 +1,6 @@
> +/* PR middle-end/111754 */
> /* { dg-do compile } */
> -/* { dg-options "-O2 -fdump-tree-optimized" } */
> +/* { dg-additional-options "-O2 -fdump-tree-forwprop1 -Wno-psabi" } */
>
> typedef float __attribute__((__vector_size__ (16))) F;
>
> @@ -9,5 +10,5 @@ F foo (F a, F b)
> return __builtin_shufflevector (v, v, 1, 0, 1, 2);
> }
>
> -/* { dg-final { scan-tree-dump-not "VEC_PERM_EXPR" "optimized" } } */
> -/* { dg-final { scan-tree-dump "return \{ 0.0, 9.0e\\+0, 0.0, 0.0 \}" "optimized" } } */
> +/* { dg-final { scan-tree-dump-not "VEC_PERM_EXPR" "forwprop1" } } */
> +/* { dg-final { scan-tree-dump "(return|<retval> =) \{ 0.0, 9.0e\\+0, 0.0, 0.0 \}" "forwprop1" } } */
>
>
> Jakub
>
@@ -1,5 +1,6 @@
+/* PR middle-end/111754 */
/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-additional-options "-O2 -fdump-tree-forwprop1 -Wno-psabi" } */
typedef float __attribute__((__vector_size__ (16))) F;
@@ -9,5 +10,5 @@ F foo (F a, F b)
return __builtin_shufflevector (v, v, 1, 0, 1, 2);
}
-/* { dg-final { scan-tree-dump-not "VEC_PERM_EXPR" "optimized" } } */
-/* { dg-final { scan-tree-dump "return \{ 0.0, 9.0e\\+0, 0.0, 0.0 \}" "optimized" } } */
+/* { dg-final { scan-tree-dump-not "VEC_PERM_EXPR" "forwprop1" } } */
+/* { dg-final { scan-tree-dump "(return|<retval> =) \{ 0.0, 9.0e\\+0, 0.0, 0.0 \}" "forwprop1" } } */