Well, my first comment is that this is more or less exactly what we invented define_subst to attempt to handle. Could we have more constructive feedback on that mechanism rather than inventing a new mechanism private to the rs6000 backend?
Hi Richard, I don't think this can be done using define_subst. To start with, we need both define_insns and define_splits. We need to be able to change constraints. We need to be able to change all match_operands in an expression into match_dups. We need to add an extra match_operand. We need to change the output template, and add alternatives to it. We need to edit the set_attrs in various ways. And we need to change the condition of the transformed instruction in a way dependent on the instruction, not the transform. We will have over 100 such define_dot_insns; any construct that is more clumsy, more verbose, more error prone is a lot more clumsy, verbose, and/or error prone. This removes about 6000 lines of rs6000.md (from the current 15000). define_subst is not flexible enough for our purpose by far, as far as I can see. But feel free to prove me wrong :-) I think define_subst will work out okay for the sign/zero- extending variants of the insns. Segher
