Some ports, notably MMIX, are using different definitions of
EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because
the same instruction may be considered invalid in reload.c and valid by
recog.c.
The opposite would be bad because after reload everything must still
adhere to the non-strict RTL definition. Luckily it cannot happen,
because the strict definition are (guess what) more strict.
I'm considering changing it to use the strict definition if
"reload_in_progress || reload_completed". I'm more comfortable with the
change because of this definition in i386/predicates.md:
if (reload_in_progress || reload_completed)
return REG_OK_FOR_INDEX_STRICT_P (op);
else
return REG_OK_FOR_INDEX_NONSTRICT_P (op);
So I would apply this patch to addressing-modes branch but I'd
appreciate advice: is the patch safe, or is there some case where
reload.c looks at constraints and reload_in_progress == 0?
/* When checking for an address, we need to handle strict vs.
non-strict
register checks. Don't use address_operand, but instead its
equivalent (its callee, which it is just a wrapper for),
memory_operand_p and the strict-equivalent
strict_memory_address_p. */
if (c == 'U')
return
- strict
+ reload_in_progress || reload_completed
? strict_memory_address_p (Pmode, x)
: memory_address_p (Pmode, x);
(Plus the removal of the strict argument, and so on).
Paolo
