Re: RFC ping: Make regname use validate_change

[Joern RENNECKE <joern dot rennecke at st dot com>]

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