This is the mail archive of the
mailing list for the GCC project.
REG_OK_STRICT and EXTRA_CONSTRAINT
- From: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- To: GCC Development <gcc at gcc dot gnu dot org>
- Cc: Hans-Peter Nilsson <hp at bitrange dot com>
- Date: Thu, 24 Aug 2006 10:22:35 +0200
- Subject: REG_OK_STRICT and EXTRA_CONSTRAINT
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
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);
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.
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
if (c == 'U')
+ 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).