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
