Re: define_split

[Joern Rennecke <amylaar at spamcop dot net>]

Quoting Paolo Bonzini <bonzini@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.