https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #16 from Michael Matz <matz at gcc dot gnu.org> --- (In reply to Richard Sandiford from comment #15) > > Yes, I considered adding this handling of (zero_extend Rx) to LRA. I'm > > confident > > it would fix this instance of the problem, if done correctly (it essentially > > already has code to deal with shortening subregs, which is somewhat similar > > in structure). > It should already be present, via the decompose_*_address mechanism. As get_index_term doesn't accept any _EXTEND as index outer code I don't see how (currently). It basically gets into the tie-breaker of leaving the operands after the loop in decompose_normal_address for baseness() to decide which of course gets it "wrong" on m68k (see my comment #5 where I checked :) ) ... > FWIW, aarch64 also supports (mem (plus (zero_extend R1) R2)) and works with > LRA, so I don't think there's a fundamental limitation. ... but obviously gets it right by luck on aarch64. > > invalid, do something". Alternatively (and better) it needs to have a way > > to say "this > > address, while structurally valid, will need these regsets in those reg > > operands", generally (i.e. it should be possible to have targets with e.g. 4 > > register operands, or such). > > > > If that's not possible then the design of the LRA-target interface is not > > yet complete IMHO. > Yeah, the current approach is the latter one (which I agree is better). > legitimate_address_p answers the question “is this address structurally > valid?” while BASE_REG_CLASS and INDEX_REG_CLASS specify the regsets that > should be used to reload registers in structurally valid addresses. Well, that then rules out targets that allow three registers in addresses. Or ones that have more complicated validity rules than "op1 here, op2 there". E.g. "when op1 is an even-numbered register, then op2 needs to be odd-numbered, and vice versa". Contrived, sure, but ISA might want to save a bit here or there in encoding. > Like you say, in practice it has to be done by using regsets, since the RA > needs to know “what do I need to do to make this valid?”. It shouldn't have > to use trial and error (trying particular hard registers to see if they're > valid). Agreed. I just think that BASE/INDEX_REG_CLASS as the only way of communicating that from the target to LRA is quite constraining. It means (like here) to always having to adjust LRA whenever a new target with other forms comes along. Basically: when the target has to look at the structure of an address to check validity (reasonably so), then it irks me that also LRA needs to get at the inner structure of those addresses for correctness. The latter part, the correctness, is what triggers me. If it's necessary for optimality: sure. But if LRA needs to be extended for correctness, then, ... meh. > > [how should stuff work without strict_p?] > > BASE_REG_CLASS and INDEX_REG_CLASS (and their variants) specify what needs > to happen for an address that doesn't currently use hard registers. And > legitimate_address_p should test whether addresses that *do* currently use > hard registers are using the right registers. (Hmm, that's quite a deviation from past, that eventually should be documented :) ) > There should be no need for the hooks to do their own > pseudo-to-hard-register lookup. The idea that one pseudo register maps to > one hard register is very simplistic and doesn't take region-based > allocation or inheritance into account. IMO it's a concept that should go > away when reload does. Well, okay, I can live with that general direction and idea. But then I think the current interface (basically just BASE/INDEX_REG_CLASS, with LRA "magically" having to do the right decision of what is index and what is base, and nothing at all possible for more than two-reg-addresses) is a bit too simplistic. It should then rather be more like an interface where the target gets an address, checks for structural validity, and if valid abstractly, then calls back into (to be provided) means in the reg-allocator to properly set regsets for each pseudo it finds in the address. Instead of the target having to rely on generic code in the reg-allocator to hopefully "correctly" deconstruct the address in just the right way to infer the proper reg-classes by itself. > And it doesn't make sense IMO to accept (say) %aN index registers or %dN > base registers at any stage, even before allocation. You mean if they are hardregs already? No, of course not, but I never was talking about addresses already having hardregs.
