[all-commits] [llvm/llvm-project] 4de852: [MachineOutliner][AArch64] NFC: Split MBBs into "o...

[Jessica Paquette via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4de8521bc528436abc47a250b2495f8b8fbc7798
      https://github.com/llvm/llvm-project/commit/4de8521bc528436abc47a250b2495f8b8fbc7798
  Author: Jessica Paquette <jpaquette at apple.com>
  Date:   2023-02-03 (Fri, 03 Feb 2023)

  Changed paths:
    M llvm/include/llvm/CodeGen/TargetInstrInfo.h
    M llvm/lib/CodeGen/MachineOutliner.cpp
    M llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
    M llvm/lib/Target/AArch64/AArch64InstrInfo.h
    A llvm/test/CodeGen/AArch64/machine-outliner-only-unsafe-ranges.mir
    A llvm/test/CodeGen/AArch64/machine-outliner-safe-range-in-middle.mir
    A llvm/test/CodeGen/AArch64/machine-outliner-unsafe-range-at-beginning.mir
    A llvm/test/CodeGen/AArch64/machine-outliner-unsafe-range-at-end.mir

  Log Message:
  -----------
  [MachineOutliner][AArch64] NFC: Split MBBs into "outlinable ranges"

Recommit with bug fixes + added testcases to the outliner. Also adds some
debug output.

We found a case in the Swift benchmarks where the MachineOutliner introduces
about a 20% compile time overhead in comparison to building without the
MachineOutliner.

The origin of this slowdown is that the benchmark has long blocks which incur
lots of LRU checks for lots of candidates.

Imagine a case like this:

```
bb:
  i1
  i2
  i3
  ...
  i123456
```

Now imagine that all of the outlining candidates appear early in the block, and
that something like, say, NZCV is defined at the end of the block.

The outliner has to check liveness for certain registers across all candidates,
because outlining from areas where those registers are used is unsafe at call
boundaries.

This is fairly wasteful because in the previously-described case, the outlining
candidates will never appear in an area where those registers are live.

To avoid this, precalculate areas where we will consider outlining from.
Anything outside of these areas is mapped to illegal and not included in the
outlining search space. This allows us to reduce the size of the outliner's
suffix tree as well, giving us a potential memory win.

By precalculating areas, we can also optimize other checks too, like whether
or not LR is live across an outlining candidate.

Doing all of this is about a 16% compile time improvement on the case.

This is likely useful for other targets (e.g. ARM + RISCV) as well, but for now,
this only implements the AArch64 path. The original "is the MBB safe" method
still works as before.