Georg-Johann Lay <a...@gjlay.de> writes: >>> 2) The secondary reload hook is always called with >>> regclass = GENERAL_REGS, even in cases where the class >>> is known to be NO_LD_REGS like, e.g. when preparing arguments >>> for a function call. Why this? I would expect to get the smallest >>> available regclass. If a reg lies in LD_REGS, a secondary reload >>> is not needed, but how can I know if class is always GENERAL_REGS? >>> Is it ensured that secondary reload hook gets never called when >>> a constraint alternative matches, like "d,i"? >> >> As far as the last bit goes: once reload has decided that it needs to >> reload A into B, it's uses the secondary reload hook (and only that hook) >> to decide whether a secondary reload is needed. The movsi constraints >> only matter when reloading a pre-reload movsi instruction. > > Ok, so even if there is an "A,B" alternative (or superset) in > respective mov insn, reload will query secondary reload hook. > > What does "reloading a pre-reload mov instruction" mean?
I just meant a move instruction that existed before reload started. If you have a movsi instruction: (set (reg:SI A) (const_int X)) before reload, then reload will use the movsi constraints to decide how to reload it. But reloads themselves are effectively move "operations" that have yet to be created. This means that there are no instructions for reload to match against. The point of the hooks is to help reload decide how these conceptual move operations should be decomposed into real instructions, and what additional temporary registers are needed for those instructions. >> I think the reason you only ever see GENERAL_REGS being passed in is >> because (from a quick look at avr.md) very few non-move patterns use >> the "d" and "l" constraints. They all seem to use the "r" constraint. >> Thus reloads from those instructions will use GENERAL_REGS rather than >> NO_LD_REGS. > > Thanks for that clarification. I though that when there is a need to > do a move, the movXX constraints would apply. > > "r" is the union of "l" and "d" just for 8- and 16-bit modes. For SI > there is reg:SI 14 which spans both "l" (14,15) and "d" (16,17) so > that this reg is neither in "l" nor "d" but in "r". So the constraint > would have to be "ldr". > > Unfortunately, the internals doc on constraints are not very > comprehensible and there is much space for misunderstanding and > speculation on how to apply them correctly. Using "ldr" over "r" would have no effect. "ldr" is the union of "l", "d" and "r", which as you say is simply "r". >> If you want to make reload use NO_LD_REGS for these GENERAL_REGS reloads, >> at least when the reloaded value is a constant, then it might be worth >> defining TARGET_PREFERRED_RELOAD_CLASS. > > It's preferred to load constants into LD_REGS, because these regs have > instructions to do that. However, LD_REGS are already very busy, and I > suspect it is no good idea to increase register pressure on them even > more. I doubt it, TBH. If reload picks a non-LD_REGS register for a constant reload, won't your secondary reload hook say that an LD_REGS temporary is needed? So you get the LD_REGS register either way. What you're doing by defining TARGET_PREFERRED_RELOAD_CLASS is avoiding the need for both an LD_REGS and a non-LD_REGS register. Richard
