On the VP side: Fast-math flag transfer from VP intrinsics to VP SDNodes. Tested through the VE parts of this patch.
For VE: Custom fusion code for VVP_FMA. Yes, there could/should be a generic DAGCombiner path for this, however, this is just the first in a series of VE-specific combiner patterns.
Details
- Reviewers
kaz7 frasercrmck craig.topper rogfer01
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/include/llvm/IR/Operator.h | ||
---|---|---|
306 | Better to expand auto here to the actual type. |
llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | ||
---|---|---|
7530 | Is this correct if the getNode call CSEs with an existing node? Should probably pass the flags to getNode. |
Fixing an SelectionDAG bug where Flags wouldn't be set in some cases of SelectionDAG::getNode. This bug fix may have (positive) trickle down effects on other targets.
Thanks!
The target independent parts look good to me. I didn't look too closely at the VE changes.
- alphabetic file order in the CMakeLists.txt
- unchanged, just to reiterate: contract only checked on the fmul, not on the fadd.
- formatting
llvm/lib/Target/VE/VVPCombine.cpp | ||
---|---|---|
30 | The specification isn't clear on this; from the LangRef: contract Allow floating-point contraction (e.g. fusing a multiply followed by an addition into a fused multiply-and-add). This does not enable reassociating to form arbitrary contractions. For example, (a*b) + (c*d) + e can not be transformed into (a*b) + ((c*d) + e) to create two fma operations. I agree with you. Intuitively, the contract only needs to be on the node that is contracted into another node. Since contraction (in the sense of FMA) means removing the implicit rounding step after the fmul. The rounding after the fadd is unaffacted by this. |
Better to expand auto here to the actual type.