Maybe expand MAX_RECOG_ALTERNATIVES ?

[Greg McGary <greg dot mcgary at gmail dot com>]

I'm working on a DSP port whose unit reservations are very sensitive to
operand signature.  E.g., for an assembler mnemonic, there can be 35-50
different combinations of operand register classes, each having different
impacts on latencies and function units.  For assembler code generation, very
few constraint alternatives are needed, but for the DFA pipeline description,
many constraint alternatives could be handy.  The maximum is currently 30, and
the implementation of genattrtab would need surgery to accommodate more.

My question is this: does it make sense to double MAX_RECOG_ALTERNATIVES so
that I can use insn attributes to identify operand signatures, or should I use
another approach?  The advantage is (presumably) lower overhead at scheduling
time--once operands are constrained, then finding the reservation comes
cheaply.  The disadvantage is that constrain_operands() is a pig, and adding
alternatives could slow it down more than it would have cost to have heavier
weight predicates in define_insn_reservation.  Also, having so many
constraints is unwieldy for define_insn, though I have found the editing job
to be reasonable when I work full-screen with 200+ columns :-).

Even if I wanted to expand MAX_RECOG_ALTERNATIVES, if no other port wants or
needs them, then a patch to genattrtab.c might not be welcome.  Before I spend
any time on genattrtab, I'd like to know now if it has any hope of being accepted.

G