[PATCH 16/18] rs6000: Test case adjustments

[Bill Schmidt]

On 11/11/21 2:06 PM, Bill Schmidt wrote:
>
>>> --- a/gcc/testsuite/gcc.target/powerpc/int_128bit-runnable.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/int_128bit-runnable.c
>>> @@ -11,9 +11,9 @@
>>>  /* { dg-final { scan-assembler-times {\mvrlq\M} 2 } } */
>>>  /* { dg-final { scan-assembler-times {\mvrlqnm\M} 2 } } */
>>>  /* { dg-final { scan-assembler-times {\mvrlqmi\M} 2 } } */
>>> -/* { dg-final { scan-assembler-times {\mvcmpequq\M} 16 } } */
>>> -/* { dg-final { scan-assembler-times {\mvcmpgtsq\M} 16 } } */
>>> -/* { dg-final { scan-assembler-times {\mvcmpgtuq\M} 16 } } */
>>> +/* { dg-final { scan-assembler-times {\mvcmpequq\M} 24 } } */
>>> +/* { dg-final { scan-assembler-times {\mvcmpgtsq\M} 26 } } */
>>> +/* { dg-final { scan-assembler-times {\mvcmpgtuq\M} 26 } } */
>>>  /* { dg-final { scan-assembler-times {\mvmuloud\M} 1 } } */
>>>  /* { dg-final { scan-assembler-times {\mvmulesd\M} 1 } } */
>>>  /* { dg-final { scan-assembler-times {\mvmulosd\M} 1 } } */
>> And this?
> Again I'm a little sketchy on the details, but I believe this resulted
> from some of the vector compares having been previously omitted by
> accident from gimple expansion.  When I added them in for the new
> support, that gave us increased counts here because the code generation
> was improved.  I'll double-check this one as well to provide a more
> certain explanation.

Upon review [1], it was the other way around.  I removed some of the
builtins from early gimple expansion because if we expand those early,
we get poor code generation instead of the vector compare instructions
we want.  As a result we get more matches in this test case.

Thanks!
Bill

[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576526.html

>
>>> --- a/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-8.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-8.c
>>> @@ -126,6 +126,7 @@ void foo (vector signed char *vscr,
>>>  /* { dg-final { scan-assembler-times "vsubcuw" 4 } } */
>>>  /* { dg-final { scan-assembler-times "vsubuwm" 4 } } */
>>>  /* { dg-final { scan-assembler-times "vbpermq" 2 } } */
>>> +/* { dg-final { scan-assembler-times "vbpermd" 0 } } */
>>>  /* { dg-final { scan-assembler-times "xxleqv" 4 } } */
>>>  /* { dg-final { scan-assembler-times "vgbbd" 1 } } */
>>>  /* { dg-final { scan-assembler-times "xxlnand" 4 } } */
>> This curious one could have been a separate (obvious) patch.  It is a
>> bit out-of-place here.
> Yeah, bit of a head-scratcher, this.  The test case probably went
> through a few revisions.  I'll test it once more and commit it
> separately.
>
>>> --- a/gcc/testsuite/gcc.target/powerpc/pragma_power8.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/pragma_power8.c
>>> @@ -19,6 +19,7 @@ test1 (vector int a, vector int b)
>>>  #pragma GCC target ("cpu=power7")
>>>  /* Force a re-read of altivec.h with new cpu target. */
>>>  #undef _ALTIVEC_H
>>> +#undef _RS6000_VECDEFINES_H
>>>  #include <altivec.h>
>> Wow ugly :-)  But nothing new here, heh.  Best not to look at testcase
>> internals too closely, in any case.
>>
>>> --- a/gcc/testsuite/gcc.target/powerpc/test_mffsl.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/test_mffsl.c
>>> @@ -1,5 +1,6 @@
>>>  /* { dg-do run { target { powerpc*-*-* } } } */
>>> -/* { dg-options "-O2 -std=c99" } */
>>> +/* { dg-options "-O2 -std=c99 -mcpu=power9" } */
>>> +/* { dg-require-effective-target powerpc_p9vector_ok } */
>>>  
>>>  #ifdef DEBUG
>>>  #include <stdio.h>
>> This one is a bug fix as well (and obvious).
> Yeah. :-(  Will handle.
>>> --- a/gcc/testsuite/gcc.target/powerpc/vsu/vec-all-nez-7.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/vsu/vec-all-nez-7.c
>>> @@ -12,5 +12,5 @@ test_all_not_equal_and_not_zero (vector unsigned short *arg1_p,
>>>    vector unsigned short arg_2 = *arg2_p;
>>>  
>>>    return __builtin_vec_vcmpnez_p (__CR6_LT, arg_1, arg_2);
>>> -  /* { dg-error "'__builtin_altivec_vcmpnezh_p' requires the '-mcpu=power9' option" "" { target *-*-* } .-1 } */
>>> +  /* { dg-error "'__builtin_altivec_vcmpnezh_p' requires the '-mpower9-vector' option" "" { target *-*-* } .-1 } */
>>>  }
>> Hrm.  People should not use the -mpower9-vector option (except implied
>> by -mcpu=power9, without vectors disabled).  How hard is it to give a
>> better error message here?
> Yeah, agreed, I think I can fix that easily enough.  There may be similar
> issues with -mpower8-vector as well that should be fixed.
>
> Thanks for the review!  I'll get back on this one soon.
>
> Bill
>
>> The obvious bugfixes independent of this series are of course okay for
>> trunk, as separate patches, now.  But some more work is needed
>> elsewhere.
>>
>>
>> Segher