Re: collapsing insns leading to a branch to a single branch-on-bit-equality insn

[Jim Wilson <wilson at redhat dot com>]

For combine to work, you would want a define_insn that has only one
set.  The example you gave had 4 sets.  Worst case, you might have to step
through combine to see what the canonical form of the instruction is after
combination, and then write a pattern that matches it.

Combine tries at most 3 instructions, so it won't work for a 4 instruction
sequence.  For a 4 instruction sequence, you could try writing a pattern that
matches the first part, emits multiple instructions, and has a condition that
is true only if the second part of the sequence is present.  The theory is that
combine will only generate the multi-insn pattern in cases where a subsequent
combine will generate the final single-insn pattern that you want.  This can
be a bit dodgy though.  It is hard to write patterns like this, and they don't
always work the way you want them to.

define_expand is only used during initial RTL generation, and only if you use
one of the predefined named patterns known to the RTL generator.  This is not
useful for your situation.

It should be possible to write a define_peephole that would work.  Your
example looks about right, except it should be a define_peephole instead of
a define_insn.  You might have to step through peephole() to see why your
define_peephole isn't working.  define_peephole is the last step before
emitting  assembly code, and only works if the instructions are all next to
each other.  If the order is different because of instruction scheduling,
then a define_peephole will fail.

You can try using define_peephole2 to get around the last problem.  This
does an RTL to RTL transformation.  So this is kind of like adding your own
combine rules.  This pass runs after reg alloc but before the (second)
scheduling pass, and hence is less likely to fail because of instruction
scheduling.

Jim