This is an archive of the discontinued LLVM Phabricator instance.

[AArch64ISelLowering] Avoid sinking mul's ops in some cases
AbandonedPublic

Authored by guopeilin on Aug 9 2021, 6:37 PM.

Details

Summary

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

Diff Detail

Event Timeline

guopeilin created this revision.Aug 9 2021, 6:37 PM
guopeilin requested review of this revision.Aug 9 2021, 6:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2021, 6:37 PM
guopeilin added inline comments.Aug 9 2021, 6:44 PM
llvm/test/CodeGen/AArch64/avoid-sinking-mul-ops.ll
87

This insertelement is not supposed to be sunk into BB.23

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.

This looks like the same issue as D107262. That commit fixes it in CGP for all users.

guopeilin abandoned this revision.Aug 16 2021, 6:56 PM