Quoting Paolo Bonzini <bonz...@gnu.org>:
As I understand it, this will also give combine the ability to do two->two (and two->N) transformations, though indirectly through the temporary insn. Given this, could you explain further the benefits of combiner-split define_split vs. define_insn_and_split.
A define_insn will be recognized in all contexts. (Unless you use special insn conditions, but the only safe place to make an insn cease to be valid in a machine-dependent way is TARGET_MACHINE_DEPENDENT_REORG. Unless you start writing extra machine-dependent passes and feed them to the pass manager.) Having an insn pattern for an insn that does not actually exist can cause all kinds of unintended consequences as the optimizers try to generate and recognize 'optimized' patterns, or when reload does its stuff.
