[all-commits] [llvm/llvm-project] 8207c8: [Legalizer] More detailed debugging printing in ma...

Roman Tereshin via All-commits all-commits at lists.llvm.org
Fri Dec 13 15:50:40 PST 2019


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 8207c81597adab5a06b50339e5ee2891f6e453bf
      https://github.com/llvm/llvm-project/commit/8207c81597adab5a06b50339e5ee2891f6e453bf
  Author: Roman Tereshin <rtereshin at apple.com>
  Date:   2019-12-13 (Fri, 13 Dec 2019)

  Changed paths:
    M llvm/lib/CodeGen/GlobalISel/Legalizer.cpp

  Log Message:
  -----------
  [Legalizer] More detailed debugging printing in main loop


  Commit: 18bf9670aac901f71bc43ac55c5feb603555a1f6
      https://github.com/llvm/llvm-project/commit/18bf9670aac901f71bc43ac55c5feb603555a1f6
  Author: Roman Tereshin <rtereshin at apple.com>
  Date:   2019-12-13 (Fri, 13 Dec 2019)

  Changed paths:
    M llvm/include/llvm/CodeGen/GlobalISel/Legalizer.h
    M llvm/lib/CodeGen/GlobalISel/Legalizer.cpp
    M llvm/unittests/CodeGen/GlobalISel/CMakeLists.txt
    A llvm/unittests/CodeGen/GlobalISel/LegalizerTest.cpp
    M llvm/utils/gn/secondary/llvm/unittests/CodeGen/GlobalISel/BUILD.gn

  Log Message:
  -----------
  [Legalizer] Refactoring out legalizeMachineFunction

and introducing new unittests/CodeGen/GlobalISel/LegalizerTest.cpp
relying on it to unit test the entire legalizer algorithm (including the
top-level main loop).

See also https://reviews.llvm.org/D71448


  Commit: 8731799fc6cf70bf4de5688ada506a222272a6a2
      https://github.com/llvm/llvm-project/commit/8731799fc6cf70bf4de5688ada506a222272a6a2
  Author: Roman Tereshin <rtereshin at apple.com>
  Date:   2019-12-13 (Fri, 13 Dec 2019)

  Changed paths:
    M llvm/include/llvm/CodeGen/GlobalISel/LegalizationArtifactCombiner.h
    M llvm/lib/CodeGen/GlobalISel/Legalizer.cpp
    M llvm/lib/Target/Mips/MipsRegisterBankInfo.cpp
    M llvm/test/CodeGen/AArch64/GlobalISel/arm64-fallback.ll
    M llvm/test/CodeGen/AArch64/GlobalISel/legalize-merge-values.mir
    M llvm/test/CodeGen/AArch64/GlobalISel/legalizer-combiner-zext-trunc-crash.mir
    M llvm/test/CodeGen/AArch64/GlobalISel/retry-artifact-combine.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/artifact-combiner-sext.mir
    M llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-fcopysign.mir
    M llvm/unittests/CodeGen/GlobalISel/LegalizerTest.cpp

  Log Message:
  -----------
  [Legalizer] Making artifact combining order-independent

Legalization algorithm is complicated by two facts:
1) While regular instructions should be possible to legalize in
   an isolated, per-instruction, context-free manner, legalization
   artifacts can only be eliminated in pairs, which could be deeply, and
   ultimately arbitrary nested: { [ () ] }, where which paranthesis kind
   depicts an artifact kind, like extend, unmerge, etc. Such structure
   can only be fully eliminated by simple local combines if they are
   attempted in a particular order (inside out), or alternatively by
   repeated scans each eliminating only one innermost pair, resulting in
   O(n^2) complexity.
2) Some artifacts might in fact be regular instructions that could (and
   sometimes should) be legalized by the target-specific rules. Which
   means failure to eliminate all artifacts on the first iteration is
   not a failure, they need to be tried as instructions, which may
   produce more artifacts, including the ones that are in fact regular
   instructions, resulting in a non-constant number of iterations
   required to finish the process.

I trust the recently introduced termination condition (no new artifacts
were created during as-a-regular-instruction-retrial of artifacts not
eliminated on the previous iteration) to be efficient in providing
termination, but only performing the legalization in full if and only if
at each step such chains of artifacts are successfully eliminated in
full as well.

Which is currently not guaranteed, as the artifact combines are applied
only once and in an arbitrary order that has to do with the order of
creation or insertion of artifacts into their worklist, which is a no
particular order.

In this patch I make a small change to the artifact combiner, making it
to re-insert into the worklist immediate (modulo a look-through copies)
artifact users of each vreg that changes its definition due to an
artifact combine.

Here the first scan through the artifacts worklist, while not
being done in any guaranteed order, only needs to find the innermost
pair(s) of artifacts that could be immediately combined out. After that
the process follows def-use chains, making them shorter at each step, thus
combining everything that can be combined in O(n) time.

Reviewers: volkan, aditya_nandakumar, qcolombet, paquette, aemerson, dsanders

Reviewed By: aditya_nandakumar, paquette

Tags: #llvm

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


Compare: https://github.com/llvm/llvm-project/compare/ed83942bc025...8731799fc6cf


More information about the All-commits mailing list