[LLVMdev] RFC: Add ISD nodes for mad

[Owen Anderson]

Hi Matt,

Maybe I’m missing something, but I’m unclear on how adding this ISD node will be a net improvement.  It seems like it will open a big can of worms with respect to canonical representations, and that a huge amount of both target-indepednent and target-specific code will have to be updated for it.

—Owen

> On Jan 28, 2015, at 11:52 AM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote:
> 
> 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.
> 
> 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.
> 
> -Matt
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev