[LLVMdev] RFC: Add ISD nodes for mad

[Hal Finkel]

----- Original Message -----
> From: "Matt Arsenault" <Matthew.Arsenault at amd.com>
> To: "llvmdev at cs.uiuc.edu" <LLVMdev at cs.uiuc.edu>
> Sent: Wednesday, January 28, 2015 1:52:59 PM
> Subject: [LLVMdev] RFC: Add ISD nodes for mad
> 
> Hi,
> 
> I would like to add an ISD node for an fmad operation (named either
> FMAD
> or FMULADD). It will have the semantics of returning the same result
> as
> the separate multiply and add with the intermediate rounding step,
> and
> not a differently rounded result.  The motivation is to share code
> with
> the various FMA forming DAG combines, but will be generally more
> useful
> on targets that support it since it is OK to form without non-default
> -fp-contract modes.

Why not just reuse the existing FMA node, but add an additional parameter to indicate whether enhanced intermediate precision is required?

> 
> This would also be associated with a minor change to the description
> of
> the llvm.fmuladd intrinsic. The fmuladd intrinsic currently has what
> I
> think are poorly worded semantics for how it should behave:
> 
> "...is equivalent to the expression a * b + c, except that rounding
> will
> not be performed between the multiplication and addition steps if the
> code generator fuses the operations. Fusion is not guaranteed, even
> if
> the target platform supports it."
> 
> This is odd because it doesn't guarantee fusion, but if fusion does
> happen, the intermediate rounding is eliminated. This is an odd
> constraint to put on the backend that in my reading doesn't allow
> ever
> forming a mad with the same intermediate rounding. This is not
> helpful
> since the fmuladd intrinsic expands to the fmul and fadd in
> SelectionDAGBuilder unless fp-contraction is globally enabled.
> According
> to this constraint, you could never form a mad because if it was
> expanded from the fmuladd intrinsic, fusion is not allowed. I don't
> think this arbitrary constraint on the backend makes sense, so the
> semantics of fmuladd would be changed to mean that the intermediate
> rounding may or may not happen, but not constrain the backend on only
> fusing if the intermediate rounding is eliminated.

The fusion is an observable effect, using a "combination instruction" that does not change the rounding behavior is always allowed under the normal "as if" rule. We don't ever constrain the code generators to produce specific instructions at the IR level (even when target-specific intrinsics are used, which sometimes surprises people).

 -Hal

> 
> -Matt
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory