RFC [reload1] maybe share op_addr reloads
DJ Delorie
dj@redhat.com
Sat Dec 3 01:14:00 GMT 2005
This comment seems to explain why:
/* Scan all the reloads, and check for RELOAD_FOR_OPERAND_ADDRESS reloads.
If we have more than one, then convert all RELOAD_FOR_OPADDR_ADDR
reloads to RELOAD_FOR_OPERAND_ADDRESS reloads.
choose_reload_regs assumes that RELOAD_FOR_OPADDR_ADDR reloads never
conflict with RELOAD_FOR_OPERAND_ADDRESS reloads. This is true for a
single pair of RELOAD_FOR_OPADDR_ADDR/RELOAD_FOR_OPERAND_ADDRESS reloads.
However, if there is more than one RELOAD_FOR_OPERAND_ADDRESS reload,
then a RELOAD_FOR_OPADDR_ADDR reload conflicts with all
RELOAD_FOR_OPERAND_ADDRESS reloads other than the one that uses it.
This is complicated by the fact that a single operand can have more
than one RELOAD_FOR_OPERAND_ADDRESS reload. It is very difficult to fix
choose_reload_regs without affecting code quality, and cases that
actually fail are extremely rare, so it turns out to be better to fix
the problem here by not generating cases that choose_reload_regs will
fail for. */
This extremely rare case happens to be the case that's failing for
m32c :-P
Maybe we can conditionalize the new logic with SMALL_REGISTER_CLASSES?
More information about the Gcc-patches
mailing list