Hi!
Heh, I first thought I had mistyped thgew PR #, but it is this one after
all :-)
On Thu, Sep 22, 2022 at 09:41:34AM +0800, Kewen.Lin wrote:
> PR100645 exposes one latent bug in define_expand vec_shr_<mode>
> that the current condition TARGET_ALTIVEC is too loose. The
> mode iterator VEC_L contains a few modes, they are not always
> supported as vector mode, VECTOR_UNIT_ALTIVEC_OR_VSX_P should
> be used like some other VEC_L usages.
> --- a/gcc/config/rs6000/vector.md
> +++ b/gcc/config/rs6000/vector.md
> @@ -1475,7 +1475,7 @@ (define_expand "vec_shr_<mode>"
> [(match_operand:VEC_L 0 "vlogical_operand")
> (match_operand:VEC_L 1 "vlogical_operand")
> (match_operand:QI 2 "reg_or_short_operand")]
> - "TARGET_ALTIVEC"
> + "VECTOR_UNIT_ALTIVEC_OR_VSX_P (<MODE>mode)"
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr100645.c
> @@ -0,0 +1,13 @@
> +/* { dg-require-effective-target powerpc_altivec_ok } */
> +/* { dg-options "-mdejagnu-cpu=power6 -maltivec" } */
This is a strange choice: we normally do not enable VMX on p6. Just use
p7 instead? There is no need for altivec_ok in any case, the -mcpu=
guarantees it is satisfied.
> +/* It's to verify no ICE here. */
"This used to ICE."?
Please commit this now, looks good. Thanks!
Segher
