Quoting Georg-Johann Lay <a...@gjlay.de>:
OPTIMIZE_MODE_SWITCHING looks rempting but it runs prior to reload, and many uses of ZERO or TMP generated in reload or peep2. We would need a pass with similar abilities running after peep2.
Actually, optimize_mode_switching used to run after reload, and its EMIT_HARD_REG_SET interface still bears witness to that - I.e. it passes you a HARD_REG_SET of live registers. You could just try if it still works after reload. You can register additional instances of a pass with a register_pass somewhere from your port or a plugin. In fact, I'm currently working on a port with interrelated switchable entities where I need a total of three instances of pass_mode_switching, plus two helper passes, to get the kind of optimized mode switching I set out to get. Although I'm not quite sure what bearing that has on different hard register address costs. I would think a set of memory constraints and differently-costed alternatives in instruction alternatives would expose the cost differences to the register allocator and reload.