[PATCH] D137483: [NFC][PowerPC] Add NFC fixes to PPCInstrinfo.cpp when getting the defined machine instruction.
ChenZheng via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 22 23:54:55 PST 2022
shchenz added inline comments.
================
Comment at: llvm/lib/Target/PowerPC/PPCInstrInfo.cpp:3394
+ } else
+ DefMI = nullptr;
}
----------------
amyk wrote:
> shchenz wrote:
> > amyk wrote:
> > > shchenz wrote:
> > > > If `OpNoForForwarding` is not changed, then the reassigned `DefMI` will not be used. Do you find any issue for this?
> > > Thanks for your comment. I believe if `OpNoForForwarding` remains as `~0U` like it is in the beginning in this case, then we did not end up finding a valid operand in pre-SSA form.
> > >
> > > I realize that we also anticipate that `DefMI` would be null as at the end we have,
> > > ```
> > > return OpNoForForwarding == ~0U ? nullptr : DefMI;
> > > ```
> > > Which will indicate that we’ll return a null `DefMI` if `OpNoForForwarding` doesn’t end up getting updated.
> > >
> > > Thus, I don’t believe this is an issue, but please do let me know if I have misunderstood your question.
> > I think the change here (reassigning `DefMI` to nullptr) does not make any functionality change, right? And it makes the code more complicated(at least now one basic block is added), so I was wondering about the benefit about this change.
> The scenario in mind that served as a motivation for this change is when `OpNoForForwarding` is changed (as opposed to not being changed). The scenario is described as:
>
> - We'll go through all of the operands on `MI` and if we end up finding an `ADDI` as the `DefMI`, we'll update `OpNoForForwarding`
> - If we've found an `ADDI` but have not yet found an `LI`, we will continue to look through all every operand until we reach the end or have found an `LI`
> - It is possible that we may reach the end and never end up finding an `LI`/`ADDI`, so `DefMI` would be pointing to the last operand while `OpNoForForwarding` would still be pointing at the previous `ADDI` operand.
>
> An example that @nemanjai brought up to me appears to illustrate this:
> ```
> addi 3, 3, 10 // This should be DefMI
> mulld 5, 10, 10
> ori 6, 9, 15 // DefMI (we've stepped through all operands until we reached the end)
> maddld 4, 3, 5, 6 // MI
>
> OpNoForForwarding: 1 (points to the `addi` seen in Operand 1)
> ```
>
> We reset the `DefMI` so that it would not be pointing at an instruction that differs from the `OpNoForForwarding` that would be originally set.
OK, thanks for explanation, I get your point now. This patch is not a NFC? We are trying to fix some bug here, the bug is not exposed because for now there is no such X/D form instruction that may have `addi` and `li` operand at same time starting from operand index 1.
Reassigning DefMI to nullptr seems conservative if the original addi is legal for peephole optimization. There is a `addi` candidate for peephole, but if the `addi` operand is not the last operand, the `DefMI` returned to caller will be set to `nullptr` with this patch's fix.
How about:
```
if (Register::isVirtualRegister(TrueReg)) {
MachineInstr *DefMIForTrueReg = MRI->getVRegDef(TrueReg);
if (DefMIForTrueReg->getOpcode() == PPC::LI || DefMIForTrueReg->getOpcode() == PPC::LI8 ||
DefMIForTrueReg->getOpcode() == PPC::ADDI ||
DefMIForTrueReg->getOpcode() == PPC::ADDI8) {
OpNoForForwarding = i;
DefMI = DefMIForTrue;
// The ADDI and LI operand maybe exist in one instruction at same
// time. we prefer to fold LI operand as LI only has one Imm operand
// and is more possible to be converted. So if current DefMI is
// ADDI/ADDI8, we continue to find possible LI/LI8.
if (DefMI->getOpcode() == PPC::LI || DefMI->getOpcode() == PPC::LI8)
break;
}
```
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D137483/new/
https://reviews.llvm.org/D137483
More information about the llvm-commits
mailing list