Use a tail policy operand instead. Inspired by the work in D105092,
but without the intrinsic interface changes.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
I think the summary/description should reference D105092?
If I've got this right, now all FMA pseudos are ostensibly "commutable" as far as LLVM's concerned, but we skip the optimization if the tail policy argument says otherwise?
I'm a bit concerned that LLVM has (at least in theory) the right to assume these instructions are commutable by checking the static MI.isCommutable() method without asking us about the tail policy. Maybe that's academic, I dunno.
Yes. I guess I didn't copy the last digit.
If I've got this right, now all FMA pseudos are ostensibly "commutable" as far as LLVM's concerned, but we skip the optimization if the tail policy argument says otherwise?
Correct.
I'm a bit concerned that LLVM has (at least in theory) the right to assume these instructions are commutable by checking the static MI.isCommutable() method without asking us about the tail policy. Maybe that's academic, I dunno.
There's no guarantee that the first two operands are commutable. So I think any user of isCommutable() needs to call findCommutedOpIndices. X86 has checks for specific immediate values for vectors compares and vector shuffles in its implementation of findCommutedOpIndices.
Fair enough, yeah. It's just a fairly unclear contract that's being entered into when you set some of these properties in TableGen, if you ask me. It's encouraging that we're not the only backend that would be affected if someone interpreted isCommutable as doing what it says on the tin.
LGTM.
llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h | ||
---|---|---|
79 | Oh, maybe this could be commented as the others are. |
clang-format not found in user’s local PATH; not linting file.