https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #22 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to Michael Matz from comment #21) > (In reply to Richard Sandiford from comment #17) > > > But if LRA needs to be extended for correctness, then, ... meh. > > But this is how it's always worked. The corresponding reload code is in > > find_reloads_address_1, which similarly tries to tear apart an address, work > > out whether something is a base or an index, and use that to calculate the > > appropriate register class. ISTM this PR is just about an inconsistency > > between the base/index identification in LRA vs reload. > > > > The reg_renumber indirection performed by GO_IF_LEGITIMATE_ADDRESS for > > reload only handled the initial register allocation. It didn't help for > > pseudos that were spilled, or were allocated to the wrong class. The > > BASE_REG_CLASS/INDEX_REG_CLASS mechanism was always required to work for > > correctness, not just optimisation. > > Yes, and I can't say that I ever liked it very much in reload either (for > basically the same reasons I'm whining now here) :-) Perhaps I have just > hoped > LRA would come up with some other solution. Yeah, I definitely agree that a different solution would nicer. Part of the problem with the current approach is obvious from the way we had BASE_REG_CLASS, then (when that wasn't enough) MODE_BASE_REG_CLASS, then MODE_BASE_REG_REG_CLASS, and finally(?) MODE_CODE_BASE_REG_CLASS. :) So I agree that it would be better for the target to say what parts of an address need reloading, and how, without any of the current guesswork.
