[llvm] [BOLT][AArch64] Expand cmpbr when reversing would overflow (PR #202998)

Rafael Auler via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 4 18:33:33 PDT 2026


================
@@ -935,12 +957,31 @@ Error LongJmpPass::runOnFunctions(BinaryContext &BC) {
           opts::SplitStrategy != opts::SplitFunctionsStrategy::CDSplit) &&
          "LongJmp cannot work with functions split in more than two fragments");
 
+  DenseMap<BinaryFunction *, BranchLivenessInfo> BranchLiveness;
----------------
rafaelauler wrote:

That exposes some danger in the current BLI design. Because BranchLivenessInfo holds a set of MCInst pointers, those might get invalidated as LongJmp pass runs (for example, as you add instructions to a BB, the vectors holding MCInsts might realloc). So when you query BLI on DenseSet::count with a new pointer, after the vector gets realloc'd, count will return something unpredictable (either zero or something else if the memory location got reused by another MCInst).

Unfortunately doing this sort of MCInst decoration is full of gotchas -- that is, if you use pointers to extend the information we're recording about an instruction. So whenever we need to persist information across CFG mutations (in this case, across multiple iterations of the layout pass, which might modify instructions), we store that info as an MCPlus annotation instead (as a special operand of the MCInst). See in DataflowAnalysis.h what happens when you do a getStateAt() call -- it fetches an annotation in the instruction, for that reason.

I guess we would also need to better manage the life cycle of BranchLivenessInfo here: when created, it annotates as appropriate -- when destroyed, it cleans up its annotations, so the annotations are not there in the CFG forever long after we don't need BranchLivenessInfo anymore.

https://github.com/llvm/llvm-project/pull/202998


More information about the llvm-commits mailing list