Paolo Bonzini <[EMAIL PROTECTED]> writes: >> If the general replacement of REG_OK_STRICT is indeed >> reload_in_progress || reload_completed, then the substitution >> *should* of course be in principle be correct (as in: subject to >> testing. ;) > Sure. After I'm done with the base_reg_class changes, I will try > modifying address_operand to be something along the lines of your U > constraint: > > return > strict > ? strict_memory_address_p (Pmode, x) > : memory_address_p (Pmode, x), > > which I'm of course hoping to write as > > return > reload_in_progress || reload_completed > ? strict_memory_address_p (Pmode, x) > : memory_address_p (Pmode, x), > > This will also affect the 'p' constraint, and in the end address your > "FIXME: This is arguably a bug in gcc." Of course, again, this is > subject to testing.
Have you prototyped this sort of change to see what kind of effect it might have on a friendly target? I'm not sure it's right. reload sometimes needs to change and re-recognise instructions with unreloaded operands while reload_in_progress. (See e.g. eliminate_regs_in_insn.) I think it's important to let reload choose between strict and non-strict matching. Richard
