rs6000 fused multiply-add patch [+ patchlet]

[Segher Boessenkool]

David Edelsohn wrote:
> 
>         The combine pass is called "combine" because it is predicated on
> combining instructions and uses decreased instructions as the goal.

Yes, I understand that.

> If more optimal instruction sequences should be used, that needs to be
> optimized by a different pass.  Your bitfield+mfcr -> logic instruction
> example might be appropriate as define_peephole2 patterns.  Your load+mask
> -> narrower load already should be handled correctly by other
> optimizations or the combiner because it seem like it should decrease the
> number of instructions.

Well, all these optimizations are already there, in simplify-rtx.c etc., it's
just that they never get done by the current combine, because it doesn't
decrease the number of rtl insns _if looking through a very small (3 insn)
window_.

> If the code size is decreasing then the number of
> instructions is decreasing, so maybe we need to add patterns transforming
> three instructions into two instructions.

That's a lot of different patterns; also, it's not only 3->2, but also 4->3
and I saw an 8->7, even.

Richard Kenner wrote:
> 
>     Without it, lots of simplifications don't ever get applied.  This results
>     in worse code.  For example, with the patch applied, bootstrap time goes
>     down by a few percent (powerpc-unknown-linux-gnu), as well as code size.
> 
>     One common example is, without the patch, computations involving bitfields
>     use mfcr insns; with it, they use logic instructions.
> 
> But that's not what combine is supposed to do!  The purpose of combine
> is what it's name says, to *combine* insns.

Yes, but sometimes doing a 2->2 simplification will allow it to do a 2->1
simplification, or two 2->2 simplifications will allow a 3->2, or maybe
some even longer chain.

If combine is supposed to apply (recursively) all possible simplifications,
it needs to do all canonicalizations that are in simplify-rtx and friends,
or it will fail to do some simplifications because the simplification
patterns assume their "sub patterns" (child nodes? nomenclature fails me)
are already simplified.

> If there is a simpler way to do an insn, it should be in the MD file.

Most of these are not machine dependent.  The mcrf thing just stuck out
because I looked at GCC itself as an example of "normal" big code, which
of course it is not (much too many bitfields).


Segher