https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049
--- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to Vladimir Makarov from comment #3) > (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). Aside from the duplicate move, the new code is actually better. It's better that it combined the shift in the add instead of the zero extend. So that part is fine. > > It would be nice if somebody bisected and found what commit resulted in the > regression. It's caused by g:8695bf78dad1a42636775843ca832a2f4dba4da3 which is a general change. subreg 0 is the canonical RTL for the operation so this now folds to it more often. > > 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. That's fair if there's no easy fix for 12. The benefits of the subreg change outweigh this downside. So I'm ok with fixing it in 13.
