in http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01489.html I've described a problem where regrename renamed a general register creating an insn which does not satisfy the insn predicate anymore.
I agree that regrename shouldn't make such replacements. Constraints are important to drive reload, and sometimes you need an insn predicate on top to verify that the operands of the insn agree. (Until recently insn predicates were also needed to handle rare special cases that could not be expressed in constraints because we ran out of distinct letters. ) Creating single-register classes is not a panacea, as it not only can lead to exponential growth of the number of patterns, but also changes REGNO_REG_CLASS, makes you rewrite all your secondary / tertiary reload code, and it marks every single register as likely spilled, thus pessimizing register allocation.
As a compromise I've suggested to just call the insn predicate.
This will still call all the "TARGET_FOO" predicates. These are basically static predicates that won't change once a set of options have been chosen. We are only interested in the insn predicates which vary in value depending on the instruction under consideration. I think the best balance between performance impact and sanity of the description language can be archived by having one of the gen* programs check if the predicate mentions insn and/or some of the operands, and/or an attribute that depends on the insn. On the other hand, the "TARGET_FOO" predicates tend to be cheap. If we have genattrtab generate a function to tell us if the insn predicate matters, that function will likely cost more than evaluating a simple predicate. A saving seems only plausible if we use a lookup table instead, i.e. avoid a change of control flow. So, on balance, I think that calling the insn predicate (if it set) is probably the best solution.
