REG_OK_STRICT and EXTRA_CONSTRAINT

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

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