Richard Sandiford schrieb: > Georg-Johann Lay <a...@gjlay.de> writes: >> 1) The internals just mention TARGET_SECONDARY_RELOAD for REG-MEM and >> for REG-REG moves, no word about REG-CONST moves. So is using >> secondary reloads for CONST_INT (or other consts) like outlined >> above a defined use case I can rely on? > > Yeah, it should be. Other targets rely on this too. E.g. MIPS allows > integers to be stored in FPRs as well as GPRs, but you can't load a > symbolic constant directly into an FPR; it has to go through a GPR. > >> 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 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. Getting the "big picture" is hardly possible from internals, and diving into reload sources is even worse. So the gaps are filled with intuition, which is often misleading or wrong. Would be great if a reload expert would add a page or so to internals to give comprehensive explanation and overview. > 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. All in all, I think the changes go to too far. I am not a reload expert, and there is room for improvement without affecting reload. Thanks anyway. >> 3) What is the "unit" of sri->extra_cost? Compared to COST_N_INSNS? >> Or compared to "?" constraint cost? > > I think it's measured in the same units as REGISTER_MOVE_COST. > (2 == a simple register move). > > Richard Johann
