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. 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. 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. > 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
