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
