[all-commits] [llvm/llvm-project] 82c8ac: [SimplifyCFG] Be more aggressive when sinking into...

Roman Lebedev via All-commits all-commits at lists.llvm.org
Thu Jan 13 12:31:09 PST 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 82c8aca93488730ce8f66101e0f3538f14b551dd
      https://github.com/llvm/llvm-project/commit/82c8aca93488730ce8f66101e0f3538f14b551dd
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2022-01-13 (Thu, 13 Jan 2022)

  Changed paths:
    M llvm/lib/Transforms/Utils/SimplifyCFG.cpp
    M llvm/test/Transforms/SimplifyCFG/X86/sink-common-code-into-unreachable.ll

  Log Message:
  -----------
  [SimplifyCFG] Be more aggressive when sinking into block followed by unreachable

I strongly believe we need some variant of this.

The main problem is e.g. that the glibc's assert has 4 parameters,
but the profitability check is only okay with one extra phi node,
so D116692 doesn't even trigger on most of the expected cases.

While that restriction probably makes sense in normal code, if we
are about to run off of a cliff (into an `unreachable`), this
successor block is unlikely so the cost to setup these PHI nodes
should not be on the hotpath, and shouldn't matter performance-wise.

Likewise, we don't sink if there are unconditional predecessors
UNLESS we'd sink at least one non-speculatable instruction,
which is a performance workaround, but if we are about to run into
`unreachable`, it shouldn't matter.

Note that we only allow the case where there are at
most unconditiona branches on the way to the unreachable block.

Differential Revision: https://reviews.llvm.org/D117045




More information about the All-commits mailing list