https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282
--- Comment #6 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- Here is my analysis of the problem. The test was successful as LRA actually did not work for the test. LRA just checked that all insn constraints were satisfied. If LRA did any transformation, the test would fail too before the latest changes in LRA. The recent changes in LRA force it to do always a live analysis. If we have an insn with the following alternative and operands 1 and 2 are different pseudos assigned to the same hard register by IRA: &r(1) = 0(2), r(3) lra-constraints.c decides that the insn does not need any transformation. If LRA live analysis is executed, it decides that pseudos in operands 1 and 2 conflicts because LRA live analysis (lra-lives.c) ignores the fact that they should be in the same hard register. Fixing this bug in LRA would require LRA live analysis to be aware of the chosen alternative and matched operands. It is a big change, implementing this would affect other targets unpredictably. Probably it is not wise to do it at this stage. I think changing pattern &r(1) = 0(2), r(3) to r(1) = 0(2), r(3) would be a right solution on the target side. The operand 1 can not get the same hard register as input operands or other early clobbered output operands because it should be the same as operand 2 which already can not be assigned to the same hard reg as other input and early clobber output operands. Although I don't know how big the part of .md file will be affected by such change.
