D91271 attempts to sink multiply's operands to the same block,
however, in some cases, some multiply's operands may already
in the same block, thus we cannot sink other operands otherwise
invalid IRs that definitions not strictly dominate uses
would be generated
Details
Details
Diff Detail
Diff Detail
Event Timeline
llvm/test/CodeGen/AArch64/avoid-sinking-mul-ops.ll | ||
---|---|---|
87 | This insertelement is not supposed to be sunk into BB.23 |
Comment Actions
Within the CodegenPrepare::tryToSinkFreeOperands, those Ops that use in the same BB as TargetBB will be skipped.
for (Use *U : reverse(OpsToSink)) { auto *UI = cast<Instruction>(U->get()); if (UI->getParent() == TargetBB || isa<PHINode>(UI)) continue; ToReplace.push_back(U); }
Thus for the Ops shuffle and insertelement of Mul generated by shouldSinkOperands, if the shuffle is already in the same BB of Mul, we will not sink the shuffle. However, the insertelement instruction will be sink right above the Mul instruction while behind the shuffle instruction. That is illegal cause def not dominate the use.
Comment Actions
This looks like the same issue as D107262. That commit fixes it in CGP for all users.
This insertelement is not supposed to be sunk into BB.23