This defines more equivalent base SD opcodes for various VP nodes, so
that getVPForBaseOpcode can do more lookups of VP-equivalent operations.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
Is this really NFC though? Might the DAGCombiner not be able to match more patterns to fma with this information?
// fold (fadd (fmul x, y), z) -> (fma x, y, z) if (isContractableFMUL(N0) && (Aggressive || N0->hasOneUse())) { return matcher.getNode(PreferredFusedOpcode, SL, VT, N0.getOperand(0), N0.getOperand(1), N1);
With knowledge about FMUL -> VP_FMUL, this code might now trigger? I'm not 100% familiar with this matcher code so it's just a hunch.
It would be good to double-check this, add tests, and/or remove "NFC" from the description.
Comment Actions
So from what I can tell, VPMatchContext can now make VP nodes from FP_EXTEND and FMAD. However there's no observable change because with the former, TLI.isFPExtFoldable returns false on RISC-V, and with the latter it's explicitly disabled with a FIXME to re-enable it at some point.
But I've removed the NFC anyway: I believe these nodes are equivalent so these folds should be correct if they are ever enabled.