[PATCH] D136754: [MachineCombiner] Extend reassociation logic to handle inverse instructions
Anton Sidorenko via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 25 02:13:34 PST 2022
asi-sc added inline comments.
================
Comment at: llvm/include/llvm/CodeGen/TargetInstrInfo.h:1193
+ virtual bool
+ isInverseInstAssociativeAndCommutative(const MachineInstr &Inst) const {
+ return false;
----------------
craig.topper wrote:
> asi-sc wrote:
> > asi-sc wrote:
> > > craig.topper wrote:
> > > > Can we not figure this out using getInverseOpcode?
> > > Do you suggest changing `isAssociativeAndCommutative` to take not only an instruction, but an opcode as well? This seems to spoil the readability of its interface. However, this will simplify the implementation.
> > I left this unchanged for now and uploaded a patch that shows how it looks like in the current design D138660 . If there is still a desire to merge `isInverseInstAssociativeAndCommutative` with `isAssociativeAndCommutative`, then we should change the latter to take not only the instruction, but the opcode as well
> > ```
> > /// Return true when \P Inst with \P Opcode is both associative and commutative.
> > virtual bool isAssociativeAndCommutative(const MachineInstr &Inst, unsinged Opcode) const;
> > ```
> > which seems to me pretty unclear from the user's point of view of this interface.
> Nevermind. My suggestion. I realize now that it requires the instruction to exist with the inverted opcode.
>
> Would it make sense to pass an `Invert` bool to isAssociativeAndCommutative so we don't need to two interfaces?
Good suggestion, thanks! I've added `Invert` bool flag. One thing I'd like to mention explicitly is that I've added the default value to `Invert` argument. In general, it's dangerous in C++ to combine virtual functions and default argument values. However, I can't imagine the situation when a specific target decides to use another default value for the argument as it'll break machine combiner logic. So, exactly in this case I think it's completely safe.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D136754/new/
https://reviews.llvm.org/D136754
More information about the llvm-commits
mailing list