The intention of fmuladd is that it represents an fmul and an fadd that
may be fused with each other but may not be fused with any other
instructions. If the fmuladd is marked as contractable then this
restriction disappears, so we should canonicalize it to separate
(contractable) fmul and fadd instructions, which are generally better
supported by InstCombine and other optimization passes.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thread about the intention of fmuladd: https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20120528/143601.html
Checking fast is way too much. At most it might also need nsz, but I'm pretty sure contract is sufficient
llvm/test/Transforms/InstCombine/fma.ll | ||
---|---|---|
230 | Could use tests that other flags are preserved |
Is there a test that shows the actual benefit of this, e..g due to further combines? One potential issue is that (parts of) the cost model won't consider fadd/fmul pairs as single instruction, so. there may be negative fallout in things like SLPVectorizer.
This is a question for whether we want the original combine here or to remove it. If we're going to do this it at all it should use the minimal required flags
I added test/CodeGen/AMDGPU/fmuladd-to-fma.ll which shows one case where we get better optimization. I didn't look into exactly why that happens in this case.
Could use tests that other flags are preserved