[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67145

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Well, this is a P1, so it has to be solved.  If the problem with the patch is
only in the powerpc64 add/sub carry patterns, perhaps they can be made more
flexible, plus is commutative.
Now, looking at the i?86 carry patterns, the carry operand is there in the
nested plus instead, and e.g. aarch64 seems to have a wide set of alternatives
(although there is a small difference in that the carry in that case is not a
register, but GEU) - they have add<mode>3_carryin where it is (carry + (op1 +
op2)), then *add<mode>3_carryin_alt1, where it is ((op1 + op2) + carry) and
*add<mode>3_carryin_alt2 where there is ((carry + op1) + op2) and
*add<mode>3_carryin_alt3 where there is ((carry + op2) + op1).  The last one
really surprises me, as both op1 and op2 have the same predicate/constraint, so
IMHO alt2 and alt3 are the same thing.  But ((op1 + carry) + op2) is missing
then.
For the case when the carry flag is a register, and if the RTL simplification
always puts nested plus first, it would be just about ((op1 + op2) + carry),
((carry + op1) + op2) or ((op1 + carry) + op2).  Or you could have 3 input
operands, use special predicate for them (which would allow either
gpc_reg_operand or CA_REGNO operand), and then just in insn condition require
that exactly one of the operands is the CA_REGNO and the others are not.
Would be nice to bring some consistency in between the backends in this.