https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052
--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Ilya Enkovich from comment #6)
> (In reply to amker from comment #5)
> > Not sure if stage4 is a good time for a new hook either.
> >
> > Any ideas?
>
> We can try to improve i386 address recognition to ignore operands order.
> With this patch:
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 34b57a4..b13d3f6 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -14111,8 +14111,16 @@ ix86_decompose_address (rtx addr, struct
> ix86_address *out)
> {
> if (n >= 4)
> return 0;
> - addends[n++] = XEXP (op, 1);
> - op = XEXP (op, 0);
> + if (GET_CODE (XEXP (op, 1)) == PLUS)
> + {
> + addends[n++] = XEXP (op, 0);
> + op = XEXP (op, 1);
> + }
> + else
> + {
> + addends[n++] = XEXP (op, 1);
> + op = XEXP (op, 0);
> + }
> }
> while (GET_CODE (op) == PLUS);
> if (n >= 4)
>
> I get following ASM:
>
> .L5:
> movl ind@GOTOFF(%ebx,%esi,4), %eax
> movl 12(%esp), %edi
> movl %ebp, (%edi,%eax,4)
According to discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg00190.html,
hook is probably not wanted in this case.
Bernd gave another proposal by moving combine before loop transforms is also
interesting, but it can be for GCC6.
So a backend fix would be nice.
