[PATCH] D76954: LLVM support for BB-cluster sections

[Rahman Lavaee via Phabricator via llvm-commits]

rahmanl created this revision.
rahmanl added reviewers: tmsriram, davidxl, efriedma, echristo, MaskRay.
Herald added subscribers: llvm-commits, hiraditya.
Herald added a project: LLVM.

This is an extension of basic block sections which allows emitting several hot basic blocks in the same section, in a given order.

Currently the //-basicblock-sections=list// option allows specifying unique sections for some basic blocks. For example:
!foo
!!1
!!2
!!4
instructs the compiler to emit the entry basic block and each of basic blocks #1, #2, and #4 into a separate unique section, while all the non-specified basic blocks are coalesced into a "cold" section.

With this patch, we can use the same option to specify clusters of basic blocks to be emitted into the same section. For instance:
!foo
!!0 1 2
!!4
means emitting one section containing the entry block, BB#1, and BB#2 in this order, while emitting BB#4 in a unique section of its own. Still all the excluded basic blocks go into the cold section.

One difference is that with the new approach, we don't always create a unique separate section for the entry block. It needs to be explicitly specified in the lists, or otherwise it would be coalesced into the cold section.

Another difference is with respect to the special exception section. We only create an exception section if the BB-cluster specification scatters EH pads into more than one section.

The final difference is with regards to the size directives. We now emit a size directive for every section (which possibly includes other basic blocks), while we still emit a size directive for every basic block symbol. This is analogous to how the size directives are emitted for the //-basicblock-sections=labels// binary: One size directive for the whole function and size directives for every basic block except the entry BB.

The benefit of the BB-cluster approach is that it reduces the number of basic block sections created, which in turn reduces the CFI and DebugInfo overhead, and also reduces the burden of the linker.

Another benefit is being able to reuse the assembler's JCC mitigation strategy as discussed in http://lists.llvm.org/pipermail/llvm-dev/2020-March/140134.html.

We note the BB-cluster approach is only beneficial if the optimal block order can be computed prior to compilation, using profiles and the binary generated using //-basicblock-secitons=labels// We have shown that this is possible and the performance improvements match our previous results (please refer to the link above).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D76954

Files:
  llvm/include/llvm/CodeGen/AsmPrinter.h
  llvm/include/llvm/CodeGen/MachineBasicBlock.h
  llvm/include/llvm/CodeGen/MachineFunction.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/BBSectionsPrepare.cpp
  llvm/lib/CodeGen/MIRParser/MIParser.cpp
  llvm/lib/CodeGen/MIRParser/MIRParser.cpp
  llvm/lib/CodeGen/MIRPrinter.cpp
  llvm/lib/CodeGen/MachineBasicBlock.cpp
  llvm/lib/CodeGen/MachineFunction.cpp
  llvm/test/CodeGen/X86/basicblock-sections-eh.ll
  llvm/test/CodeGen/X86/basicblock-sections-listbb.ll
  llvm/test/CodeGen/X86/basicblock-sections-mir-parse.mir
  llvm/test/CodeGen/X86/basicblock-sections-mir-print.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D76954.253207.patch
Type: text/x-patch
Size: 40854 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200327/d1e7d6b4/attachment.bin>