Re: unfused fma question

[Jeff Law <law at redhat dot com>]

On 02/23/15 10:42, Steve Ellcey wrote:
> No, I am thinking about the case where there are only non-fused multiply
> add instructions available.  To make sure I am using the right
> terminology, I am using a non-fused multiply-add to mean a single fma
> instruction that does '(a + (b * c))' but which rounds the result of '(b
> * c)' before adding it to 'a' so that there is no difference in the
> results between using this instruction and using individual add and mult
> instructions.  My understanding is that this is how the mips32r2 madd
> instruction works.
Ahhh, nevermind, nothing I said was relevant then.  I misunderstood 
completely :-)

> In this case there seems to be two ways to have GCC generate the fma
> instruction.  One is the current method using combine_instructions with
> an instruction defined as:
>
>
> 	(define_insn "*madd" (set (0) (plus (mult (1) (2))))
>          "madd.<fmt>\t%0,%3,%1,%2"
>
> The other way would be to extend the convert_mult_to_fma so that instead
> of:
>
>    if (FLOAT_TYPE_P (type)
>        && flag_fp_contract_mode == FP_CONTRACT_OFF)
>      return false
>
> it has something like:
>
>    if (FLOAT_TYPE_P (type)
>        && (flag_fp_contract_mode == FP_CONTRACT_OFF)
>        && !targetm.fma_does_rounding))
>      return false
>
> And then define an instruction like:
>
> 	(define_insn "fma" (set (0) (fma (1) (2) (3))))"
>          madd.<fmt>\t%0,%3,%1,%2"
>
>
> The question I have is whether one or the other of these two approaches
> would be better at creating fma instructions (vs leaving mult/add
> combinations) or be might be preferable for some other reason.
The combiner pattern is useful in cases where we can't see the FMA at 
gimple->rtl expansion time.  But there may be cases where exposing the 
FMA earlier is helpful as well.

So I think an argument could be easily made that we want to support both.

Jeff