This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]