Hi!
On Thu, Apr 16, 2020 at 08:21:07AM -0500, Peter Bergner wrote:
> The ICE in PR93974 is caused by a bug in decompose address not being able to
> handle Altivec addresses the use AND: to strip off the bottom address bits.
> Rather than modify lra-constraints.c or rtlanal.c to solve this generic
> problem this late in the release cycle, I have decided to fix this in target
> code by defining the TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P target hook to
> reject mems with Altivec addresses from being used as equivalent expressions.
> I think this is fine, since Altivec addresses are legacy addresses. I have
> confirmed the following patch fixes the ICE and that we still get the same
> code generated for the test case below, that we got before my PR93658 patch.
Excellent :-) Just some very minor things:
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -1734,6 +1734,9 @@ static const struct attribute_spec
> rs6000_attribute_table[] =
>
> #undef TARGET_MANGLE_DECL_ASSEMBLER_NAME
> #define TARGET_MANGLE_DECL_ASSEMBLER_NAME rs6000_mangle_decl_assembler_name
> +
> +#undef TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P
> +#define TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P
> rs6000_cannot_substitute_mem_equiv_p
This line gets too long, you could split it in two? (I did say "very
minor", right?)
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pr93974.C
> @@ -0,0 +1,27 @@
> +/* { dg-do compile { target { powerpc*-*-linux* } } } */
> +/* { dg-require-effective-target powerpc_p8vector_ok } */
> +/* { dg-options "-mdejagnu-cpu=power8 -O3 -fstack-protector-strong" } */
Is there a reason to do this on Linux only? If not, you can just do
{ dg-do compile } ?
Okay for trunk, however you choose to resolve those things. Thank you!
Segher
