According to IR LangRef, the FMF flag:
contract
Allow floating-point contraction (e.g. fusing a multiply followed by an
addition into a fused multiply-and-add).
reassoc
Allow reassociation transformations for floating-point instructions.
This may dramatically change results in floating-point.
My understanding is that these two flags shouldn't imply each other,
as we might have a SDNode that can be reassociated with others, but
not contractble.
eg: We may want following fmul/fad/fsub to freely reassoc, but don't
want fma being generated here.
%F = fmul reassoc double %A, %B ; <double> [#uses=1] %G = fmul reassoc double %C, %D ; <double> [#uses=1] %H = fadd reassoc double %F, %G ; <double> [#uses=1] %I = fsub reassoc double %H, %E ; <double> [#uses=1]
Before https://reviews.llvm.org/D45710, reassoc flag actually
did not imply isContratable either.
static bool isContractable(SDNode *N) {
SDNodeFlags F = N->getFlags(); return F.hasAllowContract() || F.hasUnsafeAlgebra();
}
The current implementation also only check the flag in fadd node,
ignoring fmul node, this patch update that as well.
Nit: it seems this function is too trivial now and we can remove it?