Old-style code generators broken?

Hi,
it looks like old-style code generators can no longer work with LLVM CVS,
because:

1. The TableGen uses the DAG from instruction to computed the number of
operands written in generated tables, and when there's no DAG, writes 0.

2. MachineInstructions::addRegOperand checks for maximum number of operands.

So, when not using DAGS in TableGen input, addRegOperand asserts on adding
the very first operand to any instruction.

If that was an explicit decision, maybe docs should be updated to say so?

- Volodya

it looks like old-style code generators can no longer work with LLVM CVS,
because:

1. The TableGen uses the DAG from instruction to computed the number of
operands written in generated tables, and when there's no DAG, writes 0.

2. MachineInstructions::addRegOperand checks for maximum number of operands.

So, when not using DAGS in TableGen input, addRegOperand asserts on adding
the very first operand to any instruction.

Right, as the code generators have improved, we've added a lot more checking and other code to the code generator.

If that was an explicit decision, maybe docs should be updated to say so?

Yup it's an explicit decision, and updated docs are welcome. If you have an instruction that takes a variable number of operands, use of the variable_ops marker in an operand list will disable the checks above (the computed number of operands is set as -1). For example, the PPC backend uses:

...
   def BL : IForm<18, 0, 1, (ops calltarget:$func, variable_ops),
                   "bl $func", BrB, >;
...

-Chris