Swap optimization pass

[Michael P. Hayes]

Jeffrey A Law writes:
 >   > I would prefer this sort of pass to run before register allocation
 >   > otherwise the chances of combining these insns gets slim since the
 >   > register constraints are usually tighter on multi-pack insns.
 > True, but in some cases you have to know what hard registers things are
 > in before trying to combine unrelated insns.  There's also likely to be
 > issues if you pack some insns, then end up having to reload inputs/outputs.

This is a standard problem with the way GCC operates and is a risk one
takes when wanting to implement more powerful, yet awkward, insns.

 > There's also the problem of instruction lengths not being finalized before
 > reload.

Is this true of LIW architectures in general?  The ones I'm familiar
with won't have this problem.

I suppose two extra passes are really needed.  A souped-up
peephole-like pass after reload like you propose (this could also act
as a reload mop-up) and another pass to handle parallel insns
(including swap instructions) before register allocation. 
To reduce compilation time, this second pass could only target the
innermost loops that are suitably small.


 > Note that introducing "foreign" insns into a libcall block tends to
 > do bad things in the register allocator, and I guess this might happen
 > in that case.
 > Even move insns will cause problems.

Yes, but the combiner currently only prevents combination with the
first insn of a libcall block.

Michael.