On Thu, 2020-04-16 at 08:21 -0500, Peter Bergner via Gcc-patches 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.
>
> This passed bootstrap and regression testing on powerpc64le-linux
> with no
> regressions. Ok for mainline?
>
> Peter
>
>
> gcc/
> PR rtl-optimization/93974
> * config/rs6000/rs6000.c (TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P): Define.
> (rs6000_cannot_substitute_mem_equiv_p): New function.
>
> gcc/testsuite/
> PR rtl-optimization/93974
> * g++.dg/pr93974.C: New test.
>
ok
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 4defc1ab52b..a723503b4dc 100644
> --- 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
>
ok
> /* Processor table. */
> @@ -26375,6 +26378,22 @@ rs6000_predict_doloop_p (struct loop *loop)
> return true;
> }
>
> +/* Implement TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P. */
> +
> +static bool
> +rs6000_cannot_substitute_mem_equiv_p (rtx mem)
> +{
> + gcc_assert (MEM_P (mem));
> +
> + /* curr_insn_transform()'s handling of subregs cannot handle altivec AND:
> + type addresses, so don't allow MEMs with those address types to be
> + substituted as an equivalent expression. See PR93974 for details. */
> + if (GET_CODE (XEXP (mem, 0)) == AND)
> + return true;
> +
> + return false;
> +}
ok
> +
> struct gcc_target targetm = TARGET_INITIALIZER;
>
> #include "gt-rs6000.h"
> diff --git a/gcc/testsuite/g++.dg/pr93974.C b/gcc/testsuite/g++.dg/pr93974.C
> new file mode 100644
> index 00000000000..ea5f2f817c1
> --- /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" } */
> +
> +class a {
> + double b[2];
> +public:
> + a();
> +};
> +
> +class c {
> +public:
> + typedef a d;
> + d m_fn1() {
> + a e;
> + return e;
> + }
> +};
> +template <typename f> void operator+(f, typename f::d);
> +void g() {
> + c connector;
> + for (;;) {
> + c cut;
> + a h = cut.m_fn1();
> + connector + h;
> + }
> +}
ok.
lgtm. :-)
thanks
-Will
