https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #3 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > We need to understand the issue at least. I think that it is not an RA problem. IRA assigns quite reasonable registers. LRA just generates 2 reloads for this test, one for insn *add_lsr_si which has only one alternative and one for insn andsi3 which needs reload insns for any alternative and LRA in this case chooses the best one. I guess the problem of the code generation regression is in some recent changes of combiner or most probably aarch64 machine dependent code directing the combiner (as Tamar wrote). It would be nice if somebody bisected and found what commit resulted in the regression. As for double transfer of the value, it could be removed by inheritance in LRA but it is impossible as an input reload pseudo got the same hard register (in LRA assignment subpass) as one of the insn output pseudo (the assignment was done in IRA) and the reloaded value is still used in subsequent insn. Unfortunately it can happen as RA can not make allocation and code selection optimally in general case. Some coordination between LRA-assignment subpass and LRA-inheritance subpass could help to avoid the double transfer but right now I have no idea how to do this. It is also dangerous to implement such coordination at this stage as LRA-inheritance sub-pass is very complicated.
