[PATCH] D156767: [AArch64] [BranchRelaxation] Optimize for hot code size in AArch64 branch relaxation

Daniel Hoekwater via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 28 10:23:20 PDT 2023


dhoekwater marked an inline comment as done.
dhoekwater added inline comments.


================
Comment at: llvm/test/CodeGen/AArch64/branch-relax-cross-section.mir:181-192
+  ; CHECK:       bb.4.cold (bbsections Cold):
+  ; CHECK-NEXT:    successors: %bb.2(0x80000000)
+  ; CHECK-NEXT:    {{ $}}
+  ; CHECK-NEXT:    early-clobber $sp, $x16 = LDRXpost $sp, 16
+  ; CHECK-NEXT:    {{ $}}
+  ; CHECK-NEXT:  bb.2.cold (bbsections Cold):
+  ; CHECK-NEXT:    successors: %bb.5(0x80000000)
----------------
dhoekwater wrote:
> dhoekwater wrote:
> > mingmingl wrote:
> > > I should have missed something here.. Where does `bb.4` and `bb.5` come from for 'x16_used_cold_to_hot'? Testing the IR (https://gcc.godbolt.org/z/esjchq3PK) gives 3 blocks.. 
> > > 
> > > Relatedly, I think submitting test cases as NFC and rebase on top of that should display the diff clearer.
> > > Where does bb.4 and bb.5 come from for 'x16_used_cold_to_hot'? 
> > 
> > `bb.3`, `bb.4`, and `bb.5` are all machine basic blocks created by the Branch Relaxation pass in the `fixupUnconditionalBranch` function.
> > - `bb.3` is a block that contains an unconditional branch that will be safely relaxed by the linker.
> > - `bb.4` is a block that restores the contents of X16 that have been written to the stack in `bb.3.entry` and clobbered by the linker. For correctness, X16 must be restored before `bb.2.cold` executes.
> > - `bb.5` is a block that contains an indirect branch to `bb.1.hot`. The indirect branch 1) loads the address of `bb.1` into an available register by loading the page address then adding the page offset and 2) branches to the register containing the address.
> > 
> > This test in particular is checking that, when a cold -> hot unconditional branch is relaxed, it eagerly inserts an indirect branch using a free register, if there is one.
> > Relatedly, I think submitting test cases as NFC and rebase on top of that should display the diff clearer.
> 
> In the NFC, do I add the MIR for the tests but not the `CHECK`s? Or do I add checks for the wrong behavior?
Tests added in an NFC.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156767/new/

https://reviews.llvm.org/D156767



More information about the llvm-commits mailing list