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
Unit Tests
Unit Tests
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.