Mikolaj Konarski pushed to branch wip/T27981-ncg-mystery-box at Glasgow Haskell Compiler / GHC

Commits:

• cc533b66
  by Sasha Bogicevic at 2026-10-31T09:18:15-04:00

  Don't report -XStrict-generated bangs under -Wredundant-bang-patterns
  
  The -XStrict flag causes the desugarer to insert bang patterns.
  These are not user-written, so -Wredundant-bang-patterns must not
  report them.
  
  To achieve this, the desugarer now tracks whether it is desugaring
  compiler-generated code (similar to the typechecker's 'tcl_in_gen_code').
  Bangs inserted by -XStrict are given generated spans, which suppresses
  the "redundant bang" warnings without otherwise affecting pattern-match
  warnings.
  
  Fixes #27323
  

• 13d38047
  by Luite Stegeman at 2026-10-31T09:19:11-04:00

  rts: tombstone Weak# copies that lose an evacuation race (#23160)
  
  Mark the losing copy of a Weak# during an evacuation race in parallel
  GC with stg_DEAD_WEAK_info. This ensures that the nonmoving GC
  doesn't follow dangling pointers, leading to crashes.
  
  Fixes #23160
  

• 63347328
  by Zubin Duggal at 2026-10-31T09:19:52-04:00

  ghci: Drop GHCi's exception context when rethrowing in ghc -e
  
  Fixes #27847.
  

• a85fef3f
  by Zubin Duggal at 2026-10-31T09:19:52-04:00

  base: Preserve exception context in modifyIOError
  
  Fixes #27851.
  CLC proposal: https://github.com/haskell/core-libraries-committee/issues/446
  

• 1d60b591
  by Zubin Duggal at 2026-10-31T09:19:52-04:00

  base: Preserve exception context in mapException
  
  Fixes #27851.
  CLC proposal: https://github.com/haskell/core-libraries-committee/issues/446
  

• 3c029a1b
  by Zubin Duggal at 2026-10-31T09:19:52-04:00

  base: Preserve exception context when rethrowing exceptions in Handle reads
  
  Fixes #27875.
  CLC proposal: https://github.com/haskell/core-libraries-committee/issues/447
  

• ab2b317a
  by Zubin Duggal at 2026-10-31T09:19:52-04:00

  base: Preserve exception context when rethrowing exceptions in hClose
  
  Fixes #27875.
  CLC proposal: https://github.com/haskell/core-libraries-committee/issues/447
  

• f5abf277
  by Zubin Duggal at 2026-10-31T09:19:52-04:00

  base: Preserve exception context when rethrowing exceptions in Windows openFile
  
  Fixes #27875.
  CLC proposal: https://github.com/haskell/core-libraries-committee/issues/447
  

• d842c672
  by Zubin Duggal at 2026-10-31T09:19:52-04:00

  base: Preserve exception context when rethrowing exceptions in executablePath
  
  Fixes #27875.
  CLC proposal: https://github.com/haskell/core-libraries-committee/issues/447
  

• c5a8bb9f
  by Simon Peyton Jones at 2026-10-31T09:20:34-04:00

  Simplify a tc-trace which could crash the compiler
  
  The trace formatted an error message, which prematurely
  read the ExpType in a FunResCtxt.
  
  Solution: don't put call the error message formatting
  when tc-tracing.
  

• ab49b1d2
  by Simon Peyton Jones at 2026-10-31T09:20:34-04:00

  Tiny comment change to uniqAway
  

• 6efe4ba3
  by Simon Peyton Jones at 2026-10-31T09:20:34-04:00

  Make niFixSubst idempotent
  
  I discovered (when fixing #27994) that `niFixSubst` didn't actually
  generate an idempotent subsitution despite its claims.  It could
  return a substitution that mentions domain variables on in its range,
  when those variables are hidden inside the kind of a type variable
  occurrence.  As a result it can generate ill-kinded types. Boo!
  
  The fix is simple, and uses deep substitution.
  See Note [Finding the substitution fixpoint]
  
  I don't think it actually /caused/ any bugs, so there is no
  regression test.
  

• 3b60ae7e
  by Simon Peyton Jones at 2026-10-31T09:20:34-04:00

  Fix a nasty bug in fundeps
  
  This MR fixes #27994, which turned out to be very tricky.
  
  See Note [Exploiting closed type famililes], especially (CF7).  I was
  ending up with TyVars (not TcTyVars) in the solver, because the
  substitution computed in `getRelevantBranches` mixed the two.
  
  The code was just too clever. I ended up simplifying it quite a bit.
  For /closed/ families we no longer call `trimQtvs` (was `trim_qtvs`).
  
  Open families still do use `trimQtvs`.  See Note [trimQTvs]
  
  This patch also fixes one other buglet in the same code.
  
  * Over-saturated type families were being mis-handled.
    See the new use of `saturatedFamApp_maybe`.
  

• e4610f2d
  by Facundo Domínguez at 2026-10-31T09:21:24-04:00

  Have haddock --incremental look for the module in -this-unit-id
  

• bc6c0db6
  by sheaf at 2026-10-31T09:22:20-04:00

  mightBeFunTy: hotfix for #27979
  
  ce01ccb6 refactored 'GHC.Types.RepType.mightBeFunTy' to look through
  unary classes. That change introduced the helper function 'unwrap_type'
  which was supposed to always return an unwrapped type, but its fallback
  equation mistakenly returned the original type. This caused the
  subsequent 'tyConAppTyCon_maybe' to fail in cases where it should
  succeed (e.g. looking through foralls).
  
  In this commit, we move all the unary class unwrapping logic into
  'unwrapType' where it belonged from the start, and update the
  documentation of 'unwrapType' to better explain what it should be used
  for (#26695).
  
  Fixes #27979 #26695
  
  -------------------------
  Metric Increase:
      T5642
  -------------------------
  

• 233cce46
  by Alan Zimmerman at 2026-10-31T09:23:01-04:00

  EPA: Tidy up ExactPrint.markAnnListA' 
  
  It takes an action which can modify the AnnList, but this
  is never used. So remove it.
  

• 3594a908
  by Sylvain Henry at 2026-10-31T09:23:51-04:00

  gitmodules: ignore dirty libffi-clib submodule (#26785)
  
  `./boot` runs autoreconf in libraries/libffi-clib, which leaves
  `configure~` behind and rewrites the tracked `aclocal.m4` whenever the
  local automake version differs from the one that generated it. Every
  checkout then looks dirty. Ignore working-tree changes in the submodule
  (`ignore = dirty`); a changed submodule commit is still reported.
  
  Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
  

• 341223c0
  by Rodrigo Mesquita at 2026-10-31T09:24:33-04:00

  refactor: Keep the interactive Ids directly rather than Name
  
  Removes things like
  
      names <- map idName ids
      map (\i -> let id = find (\x -> i==idName x) names) idso
  
  and is more straightforward because there's less state going around (no
  more updating HscEnv as an output)
  
  It also kills `printTypeOfNames` completely, since now we just have the
  Ids. No longer `lookupName` names to get back the ids...
  
  ```
  printTypeOfName :: GHC.GhcMonad m => Name -> m ()
  printTypeOfName n
     = do maybe_tything <- GHC.lookupName n
          case maybe_tything of
              Nothing    -> return ()
              Just thing -> printTyThing thing
  ```
  
  now is just `printTyThing . AnId`
  
  Also:
  ```diff
  -  tythings <- catMaybes `liftM` mapM GHC.lookupName namesSorted
  -  docs <- mapM pprTypeAndContents [i | AnId i <- tythings]
  +  docs <- mapM pprTypeAndContents idsSorted
  ```
  
  (and yes, in ExecBreaks there are only Ids, no TyThings, bc they are
  only constructed by the interpreter execution which can only bind ids.
  for TyThings use runDecls which doesn't return execBreaks.)
  
  There's some care to be had to make sure we use the "most refined" Ids,
  whereas when using `Name`s we'd always fetch the most refined Id from
  scratch.
  
  Fixes #28052
  

• 54cf3c1e
  by sheaf at 2026-11-03T07:00:23-05:00

  Consolidate all CPU feature handling
  
  This commit introduces GHC.Platform.CpuFeatures which consolidates all
  of the logic for implications between CPU feature flags (mainly X86):
  
    - DynFlags now only records the set of -m<feature> flags that were
      passed, as an EnumSet CpuFeature. That keeps it a simple record of
      the flags the user passed, with no post-processing.
  
    - GHC.Platform.CpuFeatures.initCpuFeatures turns this set into a
      CpuFeatures value, applying all implications and the per-architecture
      baseline. This is the single home for all of the feature implication
      logic.
  
      Some datatypes were reworked to better reflect the implication
      structure in the types, e.g. SseAvxVersion has a strategically
      placed 'FMA' boolean.
  
    - The NCG, LLVM backend, StgToCmm, CPP defines and LLVM -mattr
      flags all consult CpuFeatures, via targetCpuFeatures.
  
  See Note [CPU features], which replaces
  Note [Implications between X86 CPU feature flags].
  
  Behaviour changes:
  
    - x86 feature flags (-msse3, -mavx, -mavx512*, -mgfni, ...) passed
      when targeting a non-x86 architecture no longer cause x86 CPP
      macros (__SSE3__, __AVX512BW__, __GFNI__, ...) to be defined, nor
      x86 attributes to be passed to LLVM.
    - Error messages reported when required CPU features are not enabled
      now print out the minimal set of flags required
      (e.g. "-mavx512vl" rather than "-mavx512f -mavx512vl").
  

• 9af64305
  by Luite Stegeman at 2026-11-03T07:01:23-05:00

  rts: move stack check to the start of the stg_unpack_cstring thunks
  
  fixes a deadlock
  
  see #27272
  

• a2208b21
  by Simon Jakobi at 2026-11-03T07:02:05-05:00

  Cmm: exclude the entry block from common block elimination
  
  a1d8139054c had fixed #27722 only partially, because it didn't prevent
  elimination of the entry block in later rounds, where the entry block is
  no longer guaranteed to come first.
  
  To close this loophole, we exclude the entry block from the CBE merge
  logic. See Note [Retain entry block during common block elimination] for
  details.
  
  This also deletes a misleading comment regarding unreachable blocks: the
  control-flow optimiser doesn't actually guarantee that no unreachable
  blocks reach CBE.
  
  Fixes #27722.
  
  Assisted-by: Claude Fable 5.1
  

• 37ad4710
  by Alan Zimmerman at 2026-11-03T07:02:46-05:00

  EPA: Use AnnList for GADT declarations
  
  Continuing the process of using AnnList to capture parser layout
  

• a7cdfe96
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  rts: run finalizers soon after the GC that finds them
  
  scheduleFinalizers puts the finalizer thread at the end of the run
  queue, and the thread whose heap overflow caused the GC goes back
  to its front unless a context switch is pending.  So under the RTS timer
  the finalizers wait for the next context switch, 20 ms by default,
  and whatever they would free stays live until then: a program that opens
  and closes handles fast keeps every closed handle's buffers. nofib's
  maillist, which appends to its output a line at a time, peaks at 18 MB
  of residency where -V0 and -C0, whose scheduler switches whenever
  another thread is runnable, keep 1.65 MB.
  
  Request a context switch when scheduling the finalizers, so that they
  run at the next block boundary. maillist then keeps 1.65 MB
  under the default timer and runs 13.2% fewer instructions.  Across
  nofib, cacheprof runs 1.2% more and gg built at -O0 0.32% more, as each
  does under -V0: run promptly, the finalizers lower the residency
  (cacheprof's peak 0.82 MB against 0.90 MB), so the major GCs, triggered
  by the old generation's size against the live data, come more often
  (cacheprof's 148 against 135).  No other program moves by 0.2% beyond
  its run-to-run noise.
  
  Fixes #28060.
  
  Assisted-by: Claude Opus 5.5
  
  

• bbe30891
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Reassociate in Cmm only where literals fold, and narrow != as ==
  
  GHC.Cmm.Opt's special case (a - b) + c ==> a + (c - b) fired whatever b
  and c were, and where c - b could not fold it put a literal on the left
  of a subtraction, which x86 cannot encode as an immediate: containers'
  Set.elemAt, at -O2, computed i + ((-1) - s) for its right step, a mov,
  a sub and an add where a sub and a dec do. It now fires only where b
  and c are literals. The reassociation (a + b) - c ==> a + (b - c) had
  the same flaw where b is a literal and c is not, turning (x * y + 1) - w
  into x * y + (1 - w), and now fires for a subtraction only where c
  is a literal. And the narrowing that compares a widened operand
  with a literal at the operand's width listed MO_Eq but not MO_Ne,
  so a byte widened to a word was tested with != after a zero extension;
  MO_Ne is added beside MO_Eq. A comparison of two operands widened alike,
  from the same width and both by zero extension or both by sign
  extension, is now done at that width as well, under the literal case's
  rule for signedness (#2080), its tables moved to the top level to serve
  both.
  
  The tests cmm_fold_lit (Cmm, the reassociation and the narrowing)
  and cmm_fold_elemAt (Haskell at -O2, the special case) fail without
  these changes.
  
  The gains: containers' set alterF:four, map elemAt and nubOrd
  noFusion_distinct, where (a - b) + c is now kept; nofib's simple
  and pic, where (a + b) - c is; vector's awshcc and nofib's
  reverse-complement, lambda and parser, where != is narrowed like ==;
  and the boot libraries' comparisons of two operands widened alike,
  in text, bytestring and ghc-internal's eqWord32, containers running
  0.02% fewer instructions by them.
  
  FIGURES FROM THE REBUILD
  
  Assisted-by: Claude Opus 5.5
  
  

• f4516e61
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Predict an inequality with a literal in static branch prediction
  
  ohPredicts, static branch prediction's opcode heuristic, predicts
  that a comparison with a literal is unlikely to come out equal,
  but it matched only MO_Eq.  The control-flow optimisation turns
  an equality into an inequality where that lets the test's true side fall
  through (Note [Invert Cmm conditionals] in GHC.Cmm.ContFlowOpt),
  and so spelt the same test went unpredicted, its two sides weighted
  alike. ohPredicts now predicts the true side of an inequality
  with a literal (0.7), as it predicts the false side of an equality,
  except where an operand is masked by MO_And, as in a pointer tag test,
  (x & 7) != 0, or a test of a bitmap's bits, or is a constructor tag: one
  read from an info table, an unboxed sum's, or a local register every
  assignment to which is a tag, which a pass over the procedure's Cmm
  finds.  Whether those bits are set, or which constructor a tag names,
  depends on the type or the data, which the CFG does not record,
  so a test of a constructor tag is predicted as before (Note [Static
  prediction of tag tests]).  Predicting every inequality made containers'
  benchmarks take up to 3.1% more instructions, through the tag tests
  of tree lookups; leaving out only pointer tag tests, intmap fromSet took
  1.3% to 1.8% more, through buildTree's bitmap test.
  
  What this removes is a tie.  In megaparsec's sepEndBy loop, a cold
  continuation's edge into the loop's second head weighs as much
  as the hot edge into it, 0.17366 each once "Hand calcFreqs a procedure's
  loops inner first" estimates them, because the test before them, written
  as != 0, is estimated 50/50; the tie gives the cold block
  the fall-through, and every element a jump.  With this commit the hot
  edge is the heavier one.
  
  The trade is k-nucleotide's hash table lookup: the exits of its bucket
  loop, written as tests for zero, come out as != 0 and are now predicted
  to stay in the loop, so that with the loop-exit heuristic the loop's
  back edge outweighs its entry; block layout gives the back edge
  the head's fall-through, and every first probe, which finds its key
  about 95% of the time, pays a jump.  The commit that lets a loop's back
  edge outrank its entry makes this layout anyway.  The gains include
  containers' intmap compareSize:n (3.45% fewer instructions), intmap
  fromListWith:randomDups (0.18% to 0.21% fewer) and nubOrd
  issue1202_repeat (0.89% fewer at -O1), and megaparsec's endBy (0.62%
  fewer).
  
  TODO: the exception goes by an operand's form, not by what decides
  the test: a parity test, its mask inside arithmetic, is predicted,
  and an evaluation test, (x & 7) != 0, is left out
  with the constructor-tag tests; predicting evaluation tests
  as evaluated, in either spelling, cost nofib 0.36% more instructions,
  and leaving parity tests out is still to be measured.
  
  FIGURES FROM THE REBUILD
  
  Assisted-by: Claude Opus 5.5
  
  

• 13aa74d4
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Find a CFG's back edges by one depth-first search
  
  findBackEdges classified every edge of the CFG (classifyEdges, which
  timestamps the visits of a depth-first search from the entry) to find
  the few that lead back to a block on the search's path. optHsPatterns
  calls it on every procedure, at every optimisation level, to give back
  edges their bonus. findBackEdges is now that depth-first search itself:
  it visits the successors in the same order and collects, as it goes,
  the edges into a block still on its stack, leaving out an edge
  from a block to itself, which classifyEdges calls a self loop rather
  than a back edge. classifyEdges and its EdgeType,
  in GHC.Data.Graph.Directed, had no other user and are gone.
  
  The generated code is the same: the assembly of perf/compiler's T3294,
  T12707, T783 and T9961 at -O0 and -O, and the object code of nofib's
  programs at -O2, are the parent's. The compiler allocates 0.2% less
  compiling T3294 at -O0, 0.7% less compiling T12707, 1.0% less compiling
  T783 and 1.0% less compiling T9961; at -O, 0.3% less compiling T12707
  and 0.2% less compiling T783; and compiling nofib's programs at -O2,
  0.20% less in geometric mean and up to 0.36% less (real/compress2).
  Compiling !16269's ManyBasicBlocks at -O1 and -O2, the compiler
  allocates 0.2% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 4dd2a50d
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Drop jumps over blocks dropJumps empties
  
  dropJumps removes a block's last jump where it can fall through
  to the next block, and a jump-only block it so empties stays as a label,
  so that a jump over it to the block after is left as a jump to the next
  instruction (x86-64's eb 00, which master's intmap benchmarks at -O1
  carry). It now looks past the blocks that are empty or that it leaves
  empty, keeping its forward recursion: a foldr from the end, tried first,
  made the compiler allocate 0.12% more compiling perf/compiler's T783
  at -O0, building the whole list before the first block.
  
  FIGURES FROM THE REBUILD
  
  Assisted-by: Claude Opus 5.5
  
  

• d3ce9189
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Let a loop's back edge outrank its entry in block layout
  
  sequenceChain lays the blocks out by fusing chains along the heaviest
  edges first, by the final edge weights. Under -fcmm-static-pred,
  on at -O1 and -O2, those are the frequencies static prediction
  estimates, which can rate a loop's back edge below its entry: where
  the branch that decides whether the loop goes on has no back edge among
  its targets, the other heuristics predict it, and they can predict
  staying in the loop to be unlikely, as in a lookup down a tree (Note
  [Static prediction of tag tests]). The entry then falls through
  into the loop's head, and every iteration pays a jump back.
  optHsPatterns gives back edges a bonus (increaseBackEdgeWeight),
  but static prediction replaces the weights of the branches
  its heuristics cover with its predictions, so that the bonus counts only
  at those it leaves alone, a heap or stack check's and those whose
  targets are all back edges. sequenceChain now raises (preferBackEdges)
  each back edge by a little more than the weight of the heaviest edge
  into its head that is not a call, a back edge or a self loop, which
  keeps the order of several back edges into one head; Note [Layout
  relevant edge weights]. A back edge out of a jump table is not raised:
  it cannot fall through, so raising it would only take the head's
  fall-through from an edge that can. Nor is a back edge out of a block
  with another successor: that block executes its branch whichever
  successor falls through, so falling through saves nothing an iteration,
  while every entry pays a jump; leaving such edges out takes 1.55% off
  intset folds:sparse foldr_elem and 0.78% off foldl_elem, and 6.4% off
  folds:dense foldl'_maximum, at -O2. preferBackEdges takes the back edges
  from findBackEdges, now exported.
  
  The garbage collector's return to the block that made a heap or stack
  check is no such loop: a back edge leaving a block that follows a failed
  check stays as it is. checkFailures, in GHC.CmmToAsm.CFG, finds
  those blocks: the targets of the less likely edges of a branch
  that getCfg tags HeapStackCheck, one whose condition reads SpLim, HpLim
  or BaseReg, and their successors, such as the block the garbage
  collector returns to, which can be a continuation that a call returns
  to as well. A block that follows such a block and whose one out-edge has
  the code generator as its source, such as a block the register allocator
  puts there, counts as following a failed check too (coldBlocks). Raising
  those back edges too makes containers' benchmarks take 0.28% more
  instructions (set fromAscList:fusion 3.2%, intset fromList:worstCase
  3.0%); leaving out the blocks that follow a failed check but
  not the block the register allocator puts after such a block, 0.09% more
  (map alter insert 0.9%). A new Note, [Frequencies before register
  allocation] in GHC.CmmToAsm.CFG, names two shapes coldBlocks misses:
  the block allocMoreStack splits off a block the garbage collector
  returns to, and a fixup block on a failure edge, which takes the edge's
  tag. A TODO at coldBlocks points there. Building the set in GHC.CmmToAsm
  instead, from checkFailures' blocks, the blocks allocMoreStack splits
  off a cold entry block and the fixup blocks on an edge out of or
  into a cold block, changed a few procedures' layout in nofib and moved
  no figure measured, while costing up to 0.03% more compile allocation
  at -O0.
  
  Nor is a back edge into the one successor of the procedure's entry block
  raised: the entry would then jump to that block at every call, which
  a loop that seldom iterates does not win back. The RTS's entry code has
  such loops, which retry on an indirection: raising their back edges made
  stg_BLACKHOLE_info, stg_enter_info and stg_forceIO_info begin
  with a jump into the loop, so that stg_BLACKHOLE_info ran an instruction
  more for every blackhole entered. Where the code generator split
  the entry block, as allocMoreStack does, and the block holding the rest
  of its code has one successor, that successor stands in for the entry's.
  
  Measured against the parent commit, in instructions; sequenceChain runs
  only under -fblock-layout-cfg, on at -O1 and -O2. At -O2 nofib's
  programs take 0.06% fewer (queens 1.7%, wheel-sieve1 1.0%), vector's
  benchmarks 0.44% fewer (leaffix 3.4%, rootfix 2.7%, listRank 2.2%),
  containers' 0.19% fewer and megaparsec's 0.25% fewer (skipMany 2.2%,
  many 1.0%); at -O1 nofib's take 0.06% fewer (queens 1.4%, knights 1.3%,
  wheel-sieve1 1.0%); fannkuch-redux moves by no more than its noise.
  
  In containers and megaparsec the rises are trades. The rule's own
  is the jump a loop's entry now pays, which its iterations seldom win
  back: intmap lookup_mixed 2.0%, whose lookups gain nothing
  from the descent that now falls through, and intset's intersection
  and difference benchmarks, 0.7 to 0.8%: the continuation that evaluates
  the second set now jumps into differenceTip's descent, a loop whose head
  has two back edges and which runs no iteration where that set is a Tip,
  as in these benchmarks, while Map's and IntMap's lookups, of the same
  shape, iterate about sixteen times an entry and gain 2.3% to 3.1%;
  no static rule tells the two apart. containers' restrictKeys,
  withoutKeys and graphFromEdges n=15, and megaparsec's hexadecimal,
  decimal and octal at -O1, pay the same jump, and so does megaparsec's
  scientific.4000, which calls decimal's decimal_: 20 instructions more,
  as decimal.4000.
  
  The fused rows, containers' map fromDistinctDescList:fusion, map and set
  fromList-distinctAsc:fusion, and map fromListWith-asc,
  fromListWithKey-asc and their :fusion rows, take 0.3% to 0.8% more
  at -O2, and set fromDistinctDescList:fusion 0.89% more. Raising back
  edges only into heads outside every enclosing loop reverts them,
  and with them nubInt's noFusion_repeat, which pays the same jump
  into IntSet's member, 1000 instructions a run, and issue1202_repeat,
  intmap lookup_mixed and intset alterF:delete:present; but it gives back
  the gains of intmap lookup_hits, lookup_most and index (3.0%),
  lookup_misses (2.6%), intset member and alterF:member (1.0% to 1.2%),
  and vector's listRank (2.5%) and awshcc (1.8%), at -O2.
  
  Where two back edges raised alike into one head tie, the static order
  breaks the tie: at -O1 megaparsec's reachOffset pays 80000 instructions
  a call, isWideChar's loop head having two back edges, tied, and the tie
  going by label order to the one that ASCII input never takes. Flipping
  the order takes 4.0% off intmap lookup_half, 2.0% off lookup_mixed
  and 1.2% off intset alterF:delete:present, and at -O1 1.1% off
  megaparsec's reachOffsetNoLine and 0.8% off errorBundlePretty, but adds
  2.5% to nofib's fasta at -O2 and 1.2% at -O1, gives back 96% of banner's
  gain, and adds 5.9% to intset fromAscList:fusion, 2.3% to fromAscList,
  1.3% to mapMonotonic and, at -O1, 0.9% to vector's next
  and prevPermutationBijective; the static order is kept.
  
  No benchmark's allocation changes beyond nofib's run-to-run noise.
  The compiler allocates 0.1% more compiling perf/compiler's T12707
  and T783 at -O; elsewhere its allocation moves by less than 0.1%.
  Compiling !16269's ManyBasicBlocks at -O1 and -O2, the compiler
  allocates 0.2% more.
  
  Assisted-by: Claude Opus 5.5
  
  

• f2867380
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Hand calcFreqs a procedure's loops inner first
  
  calcFreqs estimates block frequencies by Wu and Larus's algorithm, which
  takes the loops from inner to outer, as its comment says: an enclosing
  loop's frequencies use the cycle probability of each loop inside it,
  computed when that loop is processed. mkGlobalWeights handed
  it the loops in loopInfo's order, by back edge in the order of the CFG's
  labels, so an enclosing loop could come first. calcFreqs then took
  the probability of an inner loop's back edge itself, often 1.0,
  for that loop's cycle probability, which calcFreqs caps at 1 - 1/512,
  so the inner loop's head counted up to 512 times as often as
  it was entered. The cycle a heap check makes through the garbage
  collector is such an inner loop in any loop that allocates:
  in containers' map benchmarks, the head of the loop that looks keys up
  was estimated to run 384 times a call, while the frequencies
  of the edges into it summed to 101. mkGlobalWeights now sorts the loops
  by the size of their bodies, an inner loop's body being a proper subset
  of an enclosing one's.
  
  This makes block layout lean on the estimate more. Taking a procedure's
  loops in label order could make a head's frequency up to 512 times
  its inflow, so that the loop's back edge won by accident; where static
  prediction calls staying in a loop over a tree unlikely (Note [Static
  prediction of tag tests]), it is now the rule that a back edge outranks
  the loop's entry ("Let a loop's back edge outrank its entry in block
  layout") that keeps layout from following the estimate.
  
  Measured against the parent commit, in instructions; calcFreqs changes
  the generated code only under -fcmm-static-pred, on at -O1 and -O2.
  No nofib program moves by 0.2%, no benchmark of containers or megaparsec
  rises at -O2, and vector's benchmarks take 0.035% fewer at -O2
  (findIndexR_manual 1.06% fewer) and fannkuch-redux 0.19% fewer.
  No benchmark's allocation changes beyond nofib's run-to-run noise.
  The compiler's allocation compiling perf/compiler's T3294, T12707, T783
  and T9961 moves by less than 0.1%.
  
  Assisted-by: Claude Opus 5.5
  
  

• cfaa9bea
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Count self loops as loops in static branch prediction
  
  loopInfo took an edge for a back edge where its target dominates
  its source, by mkDomMap's sets, which hold a block's own label only
  where the block is a leaf of the dominator tree. So a self loop counted
  as a back edge only from a leaf, and the retry of an atomic operation
  that x86 emulates with a compare-and-swap loop (cmpxchg_code), whose
  block dominates the block after it, counted as none: calcFreqs then took
  that block for irreducible and gave frequency 0 to it, to every block
  it dominates and to their edges, a surrounding loop's back edge among
  them. mkDomMap's sets now hold each block's own label but the root's,
  so that a self loop counts as a back edge but at the root, which no edge
  enters as a back edge.
  
  The retry edge cmpxchg_code adds now has a TransitionSource of its own,
  AsmCodeGenRetry, which staticBranchPrediction leaves out of its rule
  that a back edge is more likely than any other edge, so that the retry
  is predicted to be rare rather than to repeat seven times in eight. Note
  [Static Branch Prediction] says so. Andreas Klebinger's !16535 overlaps
  with this commit at that edge: it builds that loop's edges
  by continueInNewBlock and addColdSelfLoop, and the two changes conflict
  there.
  
  Measured against the parent commit, on x86-64: the assembly
  of perf/compiler's T3294, T12707, T783 and T9961 at -O0 and -O
  is the same, and so are the objects of nofib's programs at -O2;
  of containers' objects only graph-benchmarks' Main changes,
  and no benchmark of containers, vector or megaparsec moves beyond
  its noise. mkDomMap's go is now one equation, and at -O the compiler
  allocates 1.9% less compiling perf/compiler's T783, 0.1% less compiling
  T12707 and 0.08% less compiling T3294; at -O0, where static prediction
  is off, its allocation does not change. Compiling !16269's
  ManyBasicBlocks at -O1 and -O2, the compiler allocates 10.7% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 5dc12312
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Specialise the linear allocator and liveness pass to x86-64
  
  The linear allocator is overloaded in the instructions and in the free
  registers, and the liveness pass in the instructions, so on x86-64 too
  they called every instruction method through a dictionary: the code
  generator is specialised for each target, but its calls of regAlloc
  and cmmTopLiveness went to the overloaded functions. Both now have
  a SPECIALISE pragma for x86's instructions, and NOINLINE [0], without
  which neither rule fires, when the boot compiler builds stage 1 or when
  the stage-1 compiler builds stage 2: cast worker/wrapper makes each
  function an alias of its body, cast to UniqDSM, and the alias inlines
  from the function's own phase whatever its rules' phase, so it inlines
  into the code generator before the call there becomes one at x86's
  instructions, which is what the rule rewrites. A phase on the SPECIALISE
  pragmas alone, [0] or [2], makes neither rule fire. linearRegAlloc
  passes the other targets' free registers through a NOINLINE function,
  which the specialiser does not specialise, so that only x86-64's get
  a copy of the allocator; Note [Specialising the linear allocator].
  The allocator's constraint synonym no longer requires Outputable free
  registers, which nothing prints, and is renamed
  from OutputableRegConstraint to RegAllocConstraint. Liveness.hs now
  imports GHC.CmmToAsm.X86 for its Instruction instance, which Linear.hs,
  importing Liveness.hs, has as well, so the allocator's modules
  that import either compile after the x86 code generator; this makes
  no import cycle, as of the allocator's modules the x86 code generator
  imports only GHC.CmmToAsm.Reg.Target.
  
  Specialising joinToTargets as well, with NOINLINE [0], saved
  the compiler less allocation than this commit does.
  
  The idea of specialising the allocator comes from the draft !4764 by Ben
  Gamari and Andreas Klebinger, which overlaps with this commit: !4764
  specialises the linear allocator to x86-64 and i386, by INLINEABLE
  pragmas on the allocator's functions and SPECIALIZE pragmas
  in GHC.CmmToAsm.X86, and this commit specialises it and the liveness
  pass to x86-64, by the SPECIALISE pragmas above.
  
  The generated code is the same: nofib's object files are byte for byte
  the parent's. The compiler allocates 1.7% less compiling perf/compiler's
  T3294 at -O0 and 0.7% less at -O, 1.2% less compiling T12707 at -O0
  and 0.4% less at -O, 1.0% less compiling T783 at -O0 and 0.2% less
  at -O, and 1.7% less compiling T9961 at -O0, though less than 0.1% less
  at -O, where CI compiles it. Compiling !16269's ManyBasicBlocks at -O1
  and -O2, the compiler allocates 0.5% less. The compiler's code grows
  by about 100 KB.
  
  Assisted-by: Claude Opus 5.5
  
  

• 95ce447a
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Record the linear allocator's spills only for -ddump-asm-stats
  
  recordSpill kept every spill and reload the linear allocator inserts,
  with its reason, in ra_spills, for the statistics -ddump-asm-stats
  prints, their only reader. It now keeps them only when that flag is on.
  The comments in GHC.CmmToAsm.Reg.Linear.Base that called the flag
  -ddrop-asm-stats now call it -ddump-asm-stats. The statistics printed
  are the same, and so is the generated code. The compiler allocates 0.20%
  less compiling perf/compiler's T3294 at -O0.
  
  Assisted-by: Claude Opus 5.5
  
  

• df8bff3a
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Check the order of liveness SCCs where jump targets are looked up
  
  computeLiveness checked that a procedure's SCCs come in reverse
  dependency order (checkIsReverseDependent) in a walk of its own,
  gathering every instruction's jump destinations, and panicked otherwise.
  The liveness pass looks every jump target's live-in registers up anyway,
  taking none for a target missing from its map; that lookup now panics
  instead, naming the target. For this, livenessSCCs enters the blocks
  of a cyclic SCC in the map before the SCC's first walk, with no register
  live, which is what the lookup took them to have, so that a target can
  be missing only where the SCCs are out of order, or where the CFG
  that gave the reachable blocks (sccBlocks) lacks it. The separate walk
  goes, and with it computeLiveness, which then only called livenessSCCs:
  regLiveness calls that itself. The generated code is the same.
  The compiler allocates 0.6% less compiling perf/compiler's T3294 at -O0
  and 0.2% less at -O, 0.5% less compiling T12707 at -O0 and 0.2% less
  at -O, 0.7% less compiling T783 at -O0 and 0.2% less at -O, and 0.7%
  less compiling T9961 at -O0. Compiling !16269's ManyBasicBlocks at -O1
  and -O2, the compiler allocates 0.1% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 2648f587
  by Mikolaj Konarski at 2026-11-03T22:23:56+01:00

  Keep a procedure's imports only where they are emitted
  
  cmmNativeGens forced the imported symbols of each procedure, rendered
  as text, to avoid a space leak, and kept them for makeImportsDoc, which
  emits them only where needImportedSymbols holds; on x86-64 Linux
  that takes -dynamic -fno-PIC. Where needImportedSymbols does not hold,
  cmmNativeGens now neither forces nor keeps them. The generated code
  is the same, also under -dynamic, -fPIC and -dynamic -fno-PIC.
  The compiler allocates 0.15% less compiling perf/compiler's T9961
  at -O0.
  
  Assisted-by: Claude Opus 5.5
  
  

• 844308b3
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Copy no register list in x86's mkRU where every register counts
  
  regUsageOfInstr on x86 and x86-64 filtered both of an instruction's
  register lists, keeping the virtual registers and the real ones
  an allocator may hand out (interesting), and so copied both lists
  for every instruction. mkRU now returns a list unchanged where every
  register in it is kept. Sylvain Henry's !16843 (GHC #28008) overlaps
  with this commit: !16843's register usage DSL tests each register
  as it adds it, but copies a list of registers it is given as it tests
  them, where this commit returns such a list unchanged when every
  register in it is kept. The generated code is the same. The compiler
  allocates 1.2% less compiling perf/compiler's T3294 at -O0 and 0.5% less
  at -O, 0.7% less compiling T12707 at -O0 and 0.2% less at -O, 0.5% less
  compiling T783 at -O0, and 1.5% less compiling T9961 at -O0. Compiling
  !16269's ManyBasicBlocks at -O1 and -O2, the compiler allocates 3.0%
  less.
  
  Assisted-by: Claude Opus 5.5
  
  

• bfa3f4b5
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Mark the registers an instruction clobbers allocated, free or not
  
  clobberRegs marked allocated those of the registers an instruction
  clobbers that were free, listing the free registers of every class
  for each instruction that writes a real register, with its own copy
  of allFreeRegs from GHC.CmmToAsm.Reg.Linear.FreeRegs, and looking each
  clobbered register up in the list. The FR class now has frClobberRegs,
  which marks the clobbered registers allocated: by default those of them
  that are free, by allFreeRegs, as clobberRegs did, since on AArch64,
  RISC-V and LoongArch allocateReg panics on a register already allocated;
  on x86-64, whose allocateReg marks a register that is not free
  as it marks a free one, it marks every one of them, listing nothing.
  clobberRegs calls it, and GHC.CmmToAsm.Reg.Linear no longer imports
  the register class modules that only the copy used. The free registers
  after a clobber are the same on every target, and so is the generated
  code on x86-64.
  
  The compiler allocates 0.1% less compiling perf/compiler's T3294 at -O0,
  0.4% less compiling T12707, 0.5% less compiling T783, and 1.2% less
  compiling T9961; at -O, 0.1% less compiling T12707. Compiling !16269's
  ManyBasicBlocks at -O1 and -O2, the compiler allocates 0.4% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• c3c51dda
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Keep an instruction's register usage in its liveness
  
  The liveness pass's backward walk computes the register usage of every
  instruction it annotates (regUsageOfInstr), and its forward walk
  (livenessForward), the linear allocator's genRaInsn and the graph
  allocator's spill cost (slurpSpillCostInfo) and spiller (regSpill_instr)
  computed it again. Liveness now keeps it (liveUsage), and those use
  the kept usage instead. patchRegsLiveInstr, which only the graph
  allocator reaches, computes the patched instruction's usage again,
  as an instruction's usage can depend on whether its registers are equal:
  x86's VXOR of a register with itself into itself reads nothing. A new
  Note in GHC.CmmToAsm.X86.Instr, [What x86's regUsageOfInstr reports],
  lists that case with the others where the usage is not what
  the processor does. This commit is, but for that Note, a subset
  of Sylvain Henry's !16843 (GHC #28008), which keeps the usage
  in the liveness annotation too and also builds it more cheaply in every
  backend; !16843 was read before this commit was written. The generated
  code is the same, with the linear allocator and with -fregs-graph.
  The compiler allocates 2.1% less compiling perf/compiler's T3294 at -O0
  and 0.8% less at -O, 1.2% less compiling T12707 at -O0 and 0.4% less
  at -O, 0.9% less compiling T783 at -O0, and 1.9% less compiling T9961
  at -O0. Compiling !16269's ManyBasicBlocks at -O1 and -O2, the compiler
  allocates 0.1% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 5b06e106
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Walk a block of a cyclic SCC again only when its successors change
  
  livenessSCCs annotated the blocks of a cyclic SCC by walking all of them
  again until the registers live on entry to every block stopped changing,
  comparing two whole block maps as lists after each round. livenessCyclic
  now walks a block again only when the registers live on entry to one
  of its successors in the SCC, or their formats, have changed since
  its last walk. The old loop compared only which registers are live
  (the Eq of Regs ignores formats), so it could stop before a wider format
  had reached every block of the SCC, the case Note [Register formats
  in liveness analysis] describes; the new one carries formats through
  as well. This fixes GHC #27619 and does what GHC #27437 asks: the walk
  itself finds the changes, and no whole block map is compared.
  This commit overlaps with Simon Jakobi's !16537, which fixes both issues
  by iterating the fixpoint over the SCC's blocks until the formats
  of the registers live on entry converge, and also removes the derived
  Ord of formats, comparing them by width: this commit follows
  it in carrying the formats through, walks again only the blocks whose
  successors changed where !16537 walks every block of the SCC each round,
  and takes its regression test T27619 unchanged. The derived Ord
  of formats, which GHC #27619 also notes and which can keep a register
  read at two vector formats at the narrower, stays, as Note [Register
  formats in liveness analysis] says.
  
  The generated code is the same on every program measured.
  Of perf/compiler's T3294, T12707, T783 and T9961, only T9961 at -O has
  a cyclic SCC, and its figure moves by 0.01%; compiling nofib's programs
  at -O2, the compiler allocates 0.12% less in geometric mean and up
  to 3.4% less (spectral/puzzle). Compiling !16269's ManyBasicBlocks
  at -O1 and -O2, the compiler allocates 24.7% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 59dc28e7
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Fill in liveBorn only for the graph allocator and -ddump-asm-liveness
  
  The liveness pass recorded, for every instruction, the registers born
  there (liveBorn), which costs a forward walk over every instruction
  of every block. Only the graph allocator and -ddump-asm-liveness use it.
  regLivenessBorn is now a pass of its own, which the graph allocator,
  its iterative variant included, runs on its input and again after
  recomputing liveness, and which CmmToAsm runs only for the dump.
  The generated code is the same, with the linear allocator
  and with -fregs-graph. The compiler allocates 2.4% less compiling
  perf/compiler's T3294 at -O0 and 0.9% less at -O, 1.7% less compiling
  T12707 at -O0 and 0.6% less at -O, 1.5% less compiling T783 at -O0
  and 0.2% less at -O, and 2.0% less compiling T9961 at -O0;
  with -fregs-graph it allocates up to 0.3% more (T9961 at -O0). Compiling
  !16269's ManyBasicBlocks at -O1 and -O2, the compiler allocates 0.5%
  less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 32cdaaff
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Prefer the register a vreg is moved into where it dies
  
  The linear allocator preferred, for a vreg, the first register
  it was recorded in on entry to any block (findPrefRealReg); a new Note,
  [The first jump into a block fixes its registers], says what the first
  jump into a block decides, that register included. The allocator now has
  preferences, tried best first. firstFreeInOrder takes the free registers
  of the vreg's class and returns the first preference among them, else
  the first of them. allocRegsAndSpill_spill takes its choice, and so does
  saveClobberedTemps, which took the first free register where it moves
  a value out of a clobbered one. This commit adds one preference, ahead
  of the first-used register: the real register the current block moves
  the vreg into where the vreg dies. A value computed into a vreg
  that the block then moves into R1, before an evaluation or a return,
  is computed in R1, and the move, now from a register to itself,
  is dropped by genRaInsn. The first-used register, which keeps a loop
  variable in one register at both ends of a loop, gains nothing
  for a value that dies in the block. Ranked after it, the new preference
  cost nofib's scs 0.2% more instructions once later commits changed
  the order of the free registers: a spilled value was reloaded
  into its first-used register and then moved into R1's register.
  processBlock builds, for each block, the map from a vreg to the register
  the block moves it into where it dies (dyingMoves, rc_moveDests).
  The preference is taken from Andreas Klebinger's draft !16693, whose
  choice of a free register prefers the real register a vreg is moved
  into where it dies, in any block (GHC #27742); this commit takes
  the moves of the current block, a subset of those.
  
  The map lives in a record of its own, RA_Context, which RA_State holds
  in one strict field (ra_context), rather than in RA_State itself, where
  an unused field alone makes the compiler allocate 0.3% more compiling
  T3294 at -O0. The NCG configuration, which the allocator uses but does
  not update either, moves there too (rc_config, was ra_config), and runR
  takes the context in its place.
  
  The expected assembly of codeGen/should_gen_asm's T24813 loses the movq
  before each function's jmp: each popcount is now computed in R1.
  
  This applies on every target the linear allocator serves; the figures
  below are x86-64's. Measured against the parent commit, in instructions:
  nofib's programs, linked with the same libraries for both, take 0.15%
  fewer (0.16% at -O1, 0.58% at -O0), none as much as 0.2% more beyond
  their run-to-run noise; vector's benchmarks 0.27% fewer, none more;
  containers' 0.39% fewer, none as much as 0.1% more beyond their noise;
  megaparsec's 0.49% fewer (skipSomeTill 1.2%, endBy1 1.2%), none more;
  fannkuch-redux moves by no more than its noise. No benchmark's
  allocation changes beyond nofib's run-to-run noise. The compiler
  allocates 0.1% more compiling perf/compiler's T12707 at -O0, 0.2% more
  compiling T783, and 0.08% more compiling T9961; compiling T3294
  its allocation moves by less than 0.1%.
  
  Assisted-by: Claude Opus 5.5
  
  

• ba1d3ff9
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Prefer a vreg's register at a recorded jump target (GHC #27980)
  
  firstFreeInOrder now puts first the register the vreg has on entry
  to a jump target of the current block whose assignment is already
  recorded (jumpLocRegs), such as a loop header jumped to from the loop's
  end: in that register the vreg needs no fixup move at the jump.
  For a target not yet reached, it takes the recorded assignments
  of the blocks that target jumps to, up to three jumps on. The first-used
  register, which a loop variable took until now, is the one the vreg
  was recorded in by whichever block recorded it first, which need
  not be the target. processBlock looks up the recorded assignments
  of the block's jump targets once, when the block starts (rc_jumpLocs,
  in RA_Context), taking the targets from a map of each block's jump
  targets that linearRegAlloc' builds once for the procedure (jumpSuccs):
  a target's assignment is recorded only at the block's jumps, after which
  no preference is looked up. Built lazily, that list makes the compiler
  allocate 0.3% more compiling perf/compiler's T3294 at -O0.
  
  In GHC #27980's reproducer the loop's continuation then reloads
  a variable straight into the register the loop header has it in,
  and the fixup block goes away. vector's quickhull and nofib's sphere
  and fibheaps show the same pattern, a rotation through a spill slot
  gone. It is a preference, applying where the block that gives the vreg
  a register jumps to a target whose assignment is recorded and the vreg's
  register there is free; the fixups of GHC #27800, of which #27980
  was closed as a duplicate, stay.
  
  This applies on every target the linear allocator serves; the figures
  below are x86-64's. Measured against the parent commit, in instructions:
  nofib's programs, vector's benchmarks and fannkuch-redux move by no more
  than their noise; containers' benchmarks take 0.01% fewer (intset
  mapMonotonic 1.3%) and megaparsec's 0.005% fewer (skipManyTill 0.1%),
  none as much as 0.1% more beyond their noise. No benchmark's allocation
  changes beyond nofib's run-to-run noise. The compiler's allocation:
  FIGURES FROM THE REBUILD.
  
  Assisted-by: Claude Opus 5.5
  
  

• 9454d380
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Prefer the register a later block moves a vreg into where it dies
  
  firstFreeInOrder now has a last preference: the real register a block
  the vreg is live into moves it into where it dies, for a vreg computed
  blocks earlier, such as R1 for a value evaluated some blocks after
  it is computed (wideMoveDests, once a procedure; rc_wideDests).
  The blocks that follow a failed heap or stack check, such
  as those calling the garbage collector, do not count: the move there
  seldom runs, and the register it names can cost a move in the hot code.
  The preference is left out where that register is live together
  with the vreg somewhere, which a walk of the blocks finds: at a block's
  entry, after an instruction's writes, and where a vreg born while
  the vreg is live is moved into that register where it dies, in the block
  it is born in.  The walk follows a vreg on into the vreg it is moved
  into where it dies, to which the allocator gives the same register,
  dropping the move; and it takes an instruction's writes
  from its register usage, liveBorn being filled in only for the graph
  allocator and the liveness dump.  Nor is it taken where another vreg
  the block reads or writes, with no location yet, has the register
  as its first-used one (rc_claims): without this, in vector's leaffix
  and listRank at -O1 a bound or an array reloaded after a call took
  its wide destination, displacing the values whose first-used register
  it is, and the loop's latch fixups grew from three instructions to five
  and six.  A vreg already given a location claims nothing, so
  that a literal in intset instanceOrd:dense keeps its wide destination
  where an already coalesced vreg has it as its first-used register.
  dyingMoves now gives moves into vregs as well, and is INLINE: out
  of line it makes the compiler allocate 1.0% more compiling
  perf/compiler's T3294 at -O0.  This preference and the earlier one
  for the current block's moves ("Prefer the register a vreg is moved
  into where it dies") together overlap with that of Andreas Klebinger's
  draft !16693, the real register a vreg is moved into where it dies,
  in any block.
  
  Counting those blocks, in containers' map foldMap_traverseSum a node
  and its field both had %rbx as their destination, the field from the hot
  block that evaluates it, the node only from the heap check's failure
  block, which calls the garbage collector; the node, allocated first,
  took %rbx, and the field, given %rax, moved into %rbx at every
  evaluation: 1.5% more instructions.  CmmToAsm takes those blocks
  from checkFailures (allocCold) and passes them to the linear allocator,
  wherever the backend maintains the CFG, -finfo-table-map or not;
  that is on x86-64 only, and elsewhere the set is empty.  Leaving out
  only the failure targets that no other edge enters, as an earlier form
  of this change did, changes no code in perf/compiler's T3294, T12707,
  T783 and T9961 or in containers' benchmarks, and makes the compiler
  allocate slightly more.
  
  The rule for a vreg born while the vreg is live keeps the register
  for the later vreg, which its own block moves into it.  Without it,
  in containers' graph buildG the loop's index and lower bound took R2's
  and R3's registers, which the block making the loop's call needed
  for its arguments, and that block ended with three moves an edge, 3.3%
  more instructions.  Counting every vreg born while the vreg is live
  and moved into the register in any block made containers' map insertWith
  take 3% more instructions: its value argument arrives in R3
  and is passed in R3 to both recursive calls, and the node's key, born
  later in the loop and moved into R3 in another block, made it lose R3
  as a preference, so every iteration moved it out of R3 and back.  Note
  [Frequencies before register allocation] gains a bullet saying
  that where blocks give a vreg different destinations the last block's
  wins, with a TODO at wideMoveDests: taking the hottest block's instead,
  by mkGlobalWeights, moved containers' benchmarks both ways by up to 1.4%
  and cost 0.24% more compile allocation, its estimate made
  for this alone.  A comment there notes that a destination no allocator
  hands out, Sp, Hp or BaseReg, stays a candidate; leaving those out
  changed no code measured and costs compile allocation.
  
  Where no preference is free, firstFreeInOrder now leaves out, while
  others remain, the free registers the current block moves another vreg
  into where it dies: a vreg given one would keep the other from being
  computed in it, or have to move out of its way.  Those registers
  are kept as a mask by register number, and the claims are walked only
  where no earlier preference is free, so that the compiler's allocation
  compiling a procedure of many C calls grows with the procedure as
  at the parent.  Without this, containers' graphFromEdges
  and stronglyConnCompR took up to 1.1% more instructions at -O1:
  the index-error block of their key lookup passes lo and hi in R3 and R4,
  so the new preference gives them those registers in the lookup's loop,
  and the array element, which has no preference, took the first free
  register, R1's, into which the loop moves the key before storing
  the element: every probe moved the element out of it first.
  
  This applies on every target the linear allocator serves; the figures
  below are x86-64's.  Measured against the parent commit,
  in instructions: nofib's programs take 0.09% fewer (0.07% at -O1, 0.06%
  at -O0), none as much as 0.2% more beyond their run-to-run noise;
  vector's benchmarks 0.26% fewer (generateIO 4%), none more; megaparsec's
  0.14% fewer (skipCount 0.9%, choice 0.6%), none more; fannkuch-redux
  moves by no more than its noise.  The benchmarks of containers take
  0.47% fewer (intset fromAscList:sparse:fusion 6.3%, intmap
  symmetricDifference 5%).  No benchmark's allocation changes beyond
  nofib's run-to-run noise.  Counting the failure blocks' moves,
  the compiler allocates 0.1% more compiling perf/compiler's T3294 at -O0,
  0.6% more compiling T12707, 0.7% more compiling T783, and 1.1% more
  compiling T9961; leaving them out takes back half or more of each.
  Compiling !16269's ManyBasicBlocks at -O1 and -O2, the compiler
  allocates 0.3% more.
  
  Some rows rise, and a later commit takes each back by undoing its cause.
  At -O1 megaparsec's endBy takes 0.5% more: its loop's join fixup,
  a cycle through the C stack that exists because the block the garbage
  collector returns to records the join's registers, gains a move
  an element; the next commit, "Allocate the blocks the garbage collector
  returns to last", removes the whole fixup, and with it the same loop's
  rotation in containers' map alter insert, 1.3% more here, and alterF
  alter insert. containers' graph buildG takes up to 2.2% more, its loop
  index, given no preference, now taking R1's register, which the call
  at the loop's end needs, so that two moves an edge remain, and intmap
  index 0.54% more; "Order x86-64 free registers around R1 and clobbering
  writes (GHC #27981)" takes both back, returning the same block
  to the shape it has at "Prefer a vreg's register at a recorded jump
  target (GHC #27980)". vector's listRank takes 2.0M more instructions
  at -O1; "Allocate a loop before a continuation that enters it" takes
  that back: there the block before the join loads straight
  into the join's registers, and the cycle through 0x40(%rsp) that holds
  this commit's move is gone.
  
  The rows of containers' intmap symmetricDifference-block, intmap
  and intset union-block, map fromDescListWithKey:fusion and map
  insertWith', and IntMap's and IntSet's union-disj_sn_swap
  and union-disj_tn_swap at -O2, two instructions more each
  by union-block's moves run once, are a trade: each pays moves in one
  procedure, following from the register choices the preference makes,
  with no local fix known; leaving the preference out reverts them
  and gives back its gains.
  
  Assisted-by: Claude Opus 5.5
  
  

• 9cc7edb8
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Allocate the blocks the garbage collector returns to last
  
  The linear allocator records, at the first jump it allocates
  into a block, the registers the block starts with, and later jumps
  into the block move their values to match. linearRA_SCCs allocated
  the SCCs in order, so the block the garbage collector returns to after
  a heap or stack check fails, which jumps back into the block that made
  the check, could be allocated before the hot path reached that block,
  and so fix the registers it starts with.  In containers' map alter
  the block that builds the new node makes such a check; its return block,
  allocated first, reloaded the new subtree into %rdi, R4, where
  the rebalancing call takes it, while the hot path still held the other
  subtree there, so the hot path reached the block through a fixup block
  rotating three registers at every level the insertion returns through.
  linearRA_SCCs now allocates those return blocks (the procedure's entry
  blocks in the set checkFailures gives, which it now takes, those
  in a cycle excepted), and any SCC only they lead to, after the others,
  so that another predecessor, in map alter the hot path, records
  the registers and the return block pays the fixup.  As it now tests
  every block for whether a jump has reached it, it looks the entry blocks
  up in a set built once rather than in their list.  This commit overlaps
  with Sylvain Henry's !16673 (GHC #27800), read before this commit
  was written: both defer, in linearRA_SCCs, return blocks outside cycles;
  !16673 those that jump into a loop, calls' continuations included,
  with the acyclic blocks only they lead to, and this commit
  those the garbage collector returns to, whether or not they jump
  into a loop, with any SCC only they lead to.
  
  Taking no wide move destination while allocating such a block, instead,
  fixes map alter but makes map insertWith take 3% more instructions,
  the mirror case: its return block, allocated first, reloads the value
  argument into R3's %rsi, its wide destination, where the hot path has
  it; without that destination it reloads it into %rax, and the hot path
  moves it out of %rsi and back at every level.  Note [Frequencies before
  register allocation] gains a bullet saying that checkFailures also
  counts as cold blocks the hot path may run, a continuation that a call
  returns to as well and a failure target that another edge enters,
  and that an estimate computed in a Cmm pass could replace
  the classification; linearRA_SCCs and checkFailures gain TODOs pointing
  there.  Where such a continuation is on the path into a loop, deferring
  it measured better than leaving it out of the set: the loop
  is then allocated first, starting from the block the garbage collector
  returns to from the loop's own check, so that the path into the loop
  pays the moves once and the loop's latches none (containers'
  set-benchmarks); leaving such continuations out costs nofib's scs 1.1%
  more instructions and vector's maximumOn 2.9%, and leaving out such
  failure targets changes no code measured and costs compile allocation.
  Allocating a loop before the path into it on purpose, by deferring
  the blocks that jump into an SCC holding an entry block, costs
  fannkuch-redux 13% at -O1, whose inner loop lies in its outer loop's
  SCC.  !16673's deferral, of every return continuation outside a cycle
  that jumps into a loop, is not used either, because it was found
  incorrect: it defers as cold a continuation that is itself inside a loop
  through the Haskell stack, and fannkuch-redux then runs 16 to 19% more
  instructions.
  
  With the return blocks allocated last, a block that reloads a value can
  find the vreg's first-used register, the one whichever block recorded
  the vreg first gave it, to be another value's: in containers' map
  fromList-distinctAsc at -O2 such a reload took it over its own wide
  destination. firstFreeInOrder now passes over the first-used register
  for the wide destination where a walk from the current block's jump
  targets, through the blocks the vreg is live into and stopping
  at those whose assignment is recorded, reaches no recorded block
  but reaches one that moves the vreg into the wide destination where
  it dies, and the value live into a block recorded with the vreg
  in the first-used register reaches none of the blocks the walk passed
  (staleWalk, staleMeets).  The vreg is then marked (markStaleFirst),
  and for a marked vreg whose walk reaches a recorded block holding
  it in another free register, that register is taken: in sequence's
  update.100 and adjust.100 at -O1, three continuations reloading
  into the same vregs then agree, where the later two kept the stale
  register and paid a swap through the C stack.  And genRaInsn reloads
  a vreg that an instruction only moves, where it dies, into a register
  free by then straight into that register, and drops the move
  (reload_into), as in map union at -O2.
  
  Measured against the parent commit, in instructions: nofib's programs
  take 0.08% fewer (wheel-sieve2 2.2%; 0.19% at -O1, fasta 10.5%), none
  as much as 0.2% more beyond their run-to-run noise; vector's benchmarks
  1.2% fewer (maximumOn 17%, minimumOn 15%); megaparsec's 2.8% fewer
  (endBy 22%, skipMany 16%); fannkuch-redux moves by no more
  than its noise. containers' benchmarks take 0.20% fewer (intset
  fromList:worstCase 8.2%, and map alter insert, the case above, 1.3%).
  No benchmark's allocation changes beyond nofib's run-to-run noise.
  The compiler's allocation: FIGURES FROM THE REBUILD.
  
  At -O1, vector's permutation benchmarks take 4.65% to 5.26% more,
  quickhull 2.3% more and nofib's knights 0.5% more: in their loops
  another predecessor now records a join's registers, one where a loop
  value with no preference has taken R1's %rbx, and the predecessors
  that receive an evaluated value in %rbx reach the join through a fixup
  that swaps or rotates registers at every iteration.  "Order x86-64 free
  registers around R1 and clobbering writes (GHC #27981)", which puts %rbx
  last in x86-64's fallback order, removes these moves in the same blocks;
  the rotation left in quickhull's split loop is there before this commit.
  
  The other rises are the deferral's price, and leaving the deferral out
  reverts them.  The blocks the garbage collector returns to now pay
  the moves into the registers the hot path recorded, by design:
  containers' main426 and $wascLinkTop pay 1404 and 868 instructions more
  a call at -O1, and $sgo2 0.05% more; and megaparsec's many pays two
  swaps through the C stack at every collection, the hot path having had
  no fixup to lose.  With the allocation order changed, other blocks move
  values between registers, with no local fix known: containers' intset
  fromAscList:sparse:fusion, map fromDescListWithKey,
  fromDistinctDescList, fromAscListWithKey, fromDistinctAscList,
  fromDistinctAscList:fusion and fromList-distinctAsc:fusion (-O1),
  IntSet's symmetricDifference-block_sn_swap and sequence update.10,
  and megaparsec's endBy1.  In vector's findIndexR, which takes 3.1% more
  at -O1, the procedure's entry now records the loop's registers,
  with the predicate in R2's %r14, where it arrives, and another loop
  value in R1's %rbx; as the loop calls the predicate through %rbx, every
  iteration moves that value out of %rbx and the predicate in, by way
  of %rdx: two moves more than before.  "Order x86-64 free registers
  around R1 and clobbering writes (GHC #27981)" puts the other value
  elsewhere, removing the move out of %rbx; not deferring a return block
  that a warm block enters takes back the rest, but costs nofib's fasta 13
  instructions an iteration at -O1, and telling a loop's only latch
  from a colder second latch needs block frequencies.  At -O1 megaparsec's
  skipMany takes 0.93% more, a move an element that lasts until "Keep Sp
  put across loops and tag tests in stack layout" removes it: the hot
  path, now allocated before the block the garbage collector returns to,
  takes the first free register where the join's recorded one is expected.
  Leaving the deferral out reverts it, with most of the procedures
  of megaparsec's bench-speed that this commit changes; extending
  the claims of "Prefer the register a later block moves a vreg into where
  it dies" to the vregs a jump target writes removes the move but makes
  many of containers' benchmarks take more instructions, intmap
  fromAscList 3.3% and intersection-mix_nn 1.0% among them.
  
  Assisted-by: Claude Opus 5.5
  
  

• ba59cc76
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Allocate a loop before a continuation that enters it
  
  The linear register allocator gives a block the assignment of the first
  jump into it that it allocates, and the SCC order puts a return
  continuation before a loop it jumps into.  Where the continuation's jump
  was the first into a block of the loop, it decided that block's
  registers, and the loop's own edges into the block paid fixup moves
  at every iteration: in the reproducer of GHC #27800, two swaps
  an iteration.
  
  Defer such a continuation, as the blocks the garbage collector returns
  to are deferred, so that the loop's own edges decide and the fixup goes
  on the continuation's edge into the loop.  This takes from !16673,
  by Sylvain Henry, its deferral of a return continuation that jumps
  into a loop, which is what fixes the issue there, as an extension
  of the series' own deferral, not as !16673's code, and adds two
  conditions it lacks:
  
    * the loop calls nothing: a loop that calls C keeps its values
      in spill slots, which a deferred continuation that is hot through
      the Haskell stack then pays for (nofib's fannkuch-redux ran 16% more
      instructions with the deferral unconditional);
    * no assignment is recorded yet for the block the continuation jumps
      into: once another jump has recorded one, deferring changes only
      the order of allocation, by which block layout breaks its ties
      (containers' intset fromAscList, one jump more an element).
  
  The deferral remains a bet that a continuation runs less often
  than the loop it jumps into, and it loses where the continuation
  is the return point of a call made at every iteration of that loop,
  which then pays the fixup at every iteration instead: megaparsec's
  reachOffsetNoLine takes 0.96% more instructions and reachOffset 0.36%
  more, nofib's mandel2 0.33% more, and containers' fused
  fromDistinctDescList rows 8.7% more at -O1.  This is the trade
  the deferral makes, its toggle the deferral itself, which reverts both
  these and the fromAscList family's gains: the cases differ only in how
  often a call path runs, which no structural order sees.  A third
  condition, deferring only a continuation whose call the loop it jumps
  into does not reach, breaks T27800, leaving a swap through a spill slot
  on both hot edges, loses every gain of containers' fromAscList family
  and vector's listRank and awshcc, makes nofib's fasta take 10.3% more
  at -O2, and leaves megaparsec's reachOffsetNoLine where this commit puts
  it.
  
  The test, T27800, is the Cmm of !16673's T27800.cmm, its assembly
  searched for swaps and spill slots: the loop's edges carry neither,
  and T27800.stderr expects the lines of the fixup on the cold edge out
  of the continuation, a swap through a spill slot.
  
  Measured against the parent commit, in instructions: vector's benchmarks
  take 0.63% fewer at -O1 (hybcc 4.5%, listRank 4.4%, awshcc 4.0%, leaffix
  3.4%) and move by no more than their noise at -O2; nofib's programs move
  by less than 0.01% at -O2 and at -O1; containers' benchmarks move
  by less than 0.01% at both levels, the fromAscList family taking 3%
  to 8% fewer, its swap through a spill slot on each back edge gone,
  and graphFromEdges up to 0.6% fewer at -O1; fannkuch-redux moves
  by no more than its noise.  No benchmark's allocation changes beyond
  nofib's run-to-run noise.  The compiler allocates at most 0.04% more
  compiling perf/compiler's T3294, T12707, T783 and T9961.
  
  Assisted-by: Claude Opus 5.5
  
  

• ca25b1e3
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Skip registers written before a saved value's next read (GHC #26631)
  
  saveClobberedTemps, saving a value out of a register an instruction
  clobbers, such as an argument register of a C call, moved it
  into the first free register in order, even one a later instruction
  of the block writes before it reads the value again; then the value
  moved again or was spilled there. It now leaves out the registers
  the rest of the block writes before it next reads the value
  (unwrittenBeforeRead), and where every free register is one, spills
  the value at once. On System V every float and vector register
  is caller-saved, so such a value live across a C call ends in memory
  anyway: in simd013 two moves and a spill before the call become one
  spill (GHC #26631). Writes in later blocks are not looked at.
  containers' intmap and map mapMaybe and nofib's x2n1
  and reverse-complement show the pattern: values crossing a C call stored
  at once rather than first moved into a caller-saved register,
  and mapMaybe's divisor kept out of %rdx, which cqto writes.
  
  Spilling at once wherever the first free register is written somewhere
  in the value's live range instead, by the clobber map that "Order x86-64
  free registers around R1 and clobbering writes (GHC #27981)" builds
  (rc_clobbers), makes fannkuch-redux take 1.1% more instructions: a loop
  bound kept in %rbx across a memcpy call is spilled and reloaded at every
  iteration, %rbx being written elsewhere in the bound's live range,
  though not before the loop reads it.
  
  This applies on every target the linear allocator serves; the figures
  below are x86-64's. Measured against the parent commit, in instructions:
  nofib's programs take 0.03% fewer (k-nucleotide 1.1%), none as much
  as 0.2% more; fannkuch-redux 0.35% fewer; containers' benchmarks 0.003%
  fewer, none more beyond their noise; megaparsec's 0.01% fewer (string
  0.1%), none more; vector's benchmarks move by no more than their noise.
  No benchmark's allocation changes beyond nofib's run-to-run noise.
  The compiler's allocation compiling perf/compiler's T3294, T12707, T783
  and T9961 moves by less than 0.1%.
  
  Assisted-by: Claude Opus 5.5
  
  

• 763c908f
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Assign literals after computed values at the end of a block
  
  GHC.Cmm.Sink emits the assignments it sinks no further at the end
  of a block, in their order. An assignment of a literal to a local
  register now goes after the later ones where each of those assigns,
  to another local register, a literal or the result of a machine
  operation that reads neither that register nor the literal's. A literal
  reads neither memory nor a register, and none of the assignments
  it passes reads or writes its register, so every value stays the same.
  
  Set first, a constant can take the register that a later value is
  to be in at the block's end, while the value's operands still hold
  the register the constant is to be in. In Data.Text's UTF-8 decoding,
  as inlined into megaparsec's benchmarks, the ASCII path sets the width,
  1, and then the character, the zero-extended byte, and jumps
  to the join, whose recorded assignment has the width in %r14
  and the character in %rbx. Once a later commit makes %rbx x86-64's last
  choice, the byte is loaded into %r14; set first, the width would
  then take %rbx and the character %r14, and the join's fixup would swap
  them at every character. Set last, the width takes %r14, and the byte
  is zero-extended into %rbx.
  
  A copy or an update in place keeps a literal before it: in a trial
  that let it pass them as well, the literal changed the registers
  of a join's recorded assignment in megaparsec's manyTill benchmark
  and of a loop head's in Text.Megaparsec.Stream's reachOffset, whose
  other predecessors then paid a move a character.
  
  Measured on x86-64 with this commit placed after the register
  allocator's commits, against the series without it: megaparsec's
  benchmarks run 0.19% fewer instructions over those stable across runs
  (someTill 1.06%, skipSomeTill 0.83%, skipSome 0.67%), none more.
  Of nofib's programs only cacheprof's and k-nucleotide's objects change,
  cacheprof's in the order of its instructions alone and k-nucleotide's
  in its registers, and none moves by as much as 0.2%; containers'
  and vector's benchmarks move by no more than their noise. The assembly
  of perf/compiler's T3294, T12707, T783 and T9961 at -O0 and -O
  is the same; at -O the compiler allocates up to 0.003% more compiling
  them (T12707) and 0.0001% more compiling !16269's ManyBasicBlocks at -O1
  and -O2; at -O0 its allocation does not change.
  
  Metric Decrease:
      CoOpt_Read
      ManyAlternatives
      ManyConstructors
      T10421
      T12425
      T12707
      T13035
      T13056
      T13253
      T13379
      T13960
      T15164
      T15304
      T15630
      T15630a
      T15703
      T18140
      T18282
      T18698a
      T18698b
      T18730
      T1969
      T20049
      T20261
      T21839c
      T24471
      T26425
      T26989
      T3064
      T3294
      T4801
      T5030
      T5321FD
      T5321Fun
      T5631
      T6048
      T783
      T9198
      T9233
      T9630
  
  Assisted-by: Claude Opus 5.5
  
  

• 54ee715c
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Prefer a loop variable's register for the value moved into it
  
  A vreg that the current block moves, where it dies, into another vreg,
  such as a loop's next index moved into the index variable before
  the jump back to the loop's header, now prefers the register
  the recorded assignment of a jump target of the block gives that other
  vreg, as it prefers a real register the block moves it into:
  processBlock adds such moves to rc_moveDests, from rc_jumpLocs.
  In that register the move goes away, and at the jump the other vreg
  is where the target's recorded assignment has it.
  
  A move counts only where the block does not write its source again
  (dyingMovesLast): a preference is looked up by the vreg, so it would
  otherwise reach the vreg's later value. Where such a move counted,
  in nofib's gcd, whose loop ends by shifting loop variables (t2C8 :=
  t2Cb, then t2Cb := a new value), the new value took the register
  the loop's header gives t2C8, and the jump to the header then had
  to exchange two registers through a stack slot: 0.4% more instructions.
  dyingMovesLast shares dyingMoves' test of a move where the vreg dies
  (dyingMove). The moves into real registers include those of a vreg
  the block writes again after the move, its later value then preferring
  that register too; leaving them out changed no code measured and costs
  compile time.
  
  This applies on every target the linear allocator serves; the figures
  below are x86-64's. Measured against the parent commit, in instructions:
  containers' benchmarks take 0.12% fewer: map lookup absent and alterF
  lookup absent 5% fewer, and lookupge-map's GE Twan 3%; fannkuch-redux
  0.01% fewer; nofib's programs and vector's benchmarks move by no more
  than their noise. No benchmark's allocation changes beyond nofib's
  run-to-run noise. The compiler's allocation compiling perf/compiler's
  T3294, T12707, T783 and T9961 moves by less than 0.1%.
  
  Assisted-by: Claude Opus 5.5
  
  

• 5aa3ae59
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Order x86-64 free registers around R1 and clobbering writes (GHC #27981)
  
  On x86-64, where none of its preferences is free, a vreg now takes R1's
  register, %rbx, last in each of the two parts below: an evaluation
  and a return write it, so a value given it may have to move out of their
  way, and a loop variable given it at the loop's entry moves at every
  iteration (GHC #27981).  Before the others it takes the registers
  no instruction writes while the vreg is live past the write: for a vreg
  live across a C call, these are the registers the call preserves,
  on System V R2's %r14 and %rbx, and for one still live where an argument
  is moved into R2's %r14 for a jump, they exclude %r14.  Given a register
  such an instruction writes, the vreg would have to move out of the way.
  Where no preference is free, firstFreeInOrder leaves out the free
  registers the block moves other vregs into where they die,
  and the register comes from a method of the FR class, frFallbackReg,
  which by default takes the first register it is given; on x86-64
  it is fallbackReg in GHC.CmmToAsm.Reg.Linear.X86_64, which takes
  the first free register in this order, R1's register taken
  from a constant rather than from globalRegMaybe at every call.
  In the reproducer of GHC #27981 this commit already removes the back
  edge's fixups; the next commit removes the cause the issue names.
  In T27800, the test of GHC #27800, the continuation's edge into the loop
  no longer swaps through a spill slot, and T27800.stderr, which expected
  those lines, is deleted.
  
  regClobbers finds, for each vreg, the registers written while
  it is live, once a procedure on x86-64: the liveness pass now records,
  at each instruction that writes a real register, the registers live
  after it (liveAcross), and regClobbers adds the written registers
  to every vreg among those that is live past the instruction, as bits
  by register number, finding the vregs an instruction writes once
  for the instruction rather than once for each vreg live past it;
  and firstFreeInOrder, which reads a vreg's first-used register twice,
  binds it strictly.  Only x86-64's fallback uses them, and on the other
  targets RA_Context's field is empty, so that no unread thunk keeps
  the procedure's code alive.  A move of the vreg itself into a register
  is no such write.  Leaving out the writes in the blocks that follow
  a failed check costs containers' lookupge-intmap Milan lookups 0.5 to 1%
  more instructions, a failure block's write having kept a vreg,
  by accident, out of a register that a later vreg is moved into; Note
  [Frequencies before register allocation] gains a bullet on the case,
  with a TODO at regClobbers.  Andreas Klebinger's draft !16693, read
  before this commit was written, charges a vreg for each register
  that an instruction in a loop starts writing while the vreg is live
  across it, and this order overlaps with that clobber cost: both steer
  a vreg away from the registers written while it is live, !16693
  by a cost counted within loops, this commit by the order of the free
  registers, from the writes met anywhere the vreg is live.
  
  On x86-64, for a vreg that has preferences, all of them taken,
  fallbackReg also leaves out, where a free register would remain,
  the registers that the recorded assignment of a jump target of the block
  gives another vreg, so that the vreg does not take a register the jump
  will need for that one: a part of what GHC #26666 asks.
  
  fallbackReg also leaves out, where others remain, the free registers
  that the blocks up to three jumps ahead that the vreg is live into move
  another vreg into where it dies, the vreg's own such destinations
  excepted: given one, the vreg would keep the other from being computed
  in it, or have to move out of its way there.  Not for a vreg live across
  a C call, which leaves its register at the call anyway: a block after
  the call, such as k-nucleotide's copy of a new key, would put it
  on an argument register that the call's own setup needs,
  and the arguments were swapped through %r9.  Nor where a jump target
  not yet recorded that the vreg is live into has two or more
  predecessors, those after a failed heap or stack check not counted:
  its register there binds them all, and a walk from one of them reaching
  a rare exit put megaparsec's manyTill counter on a register its hot
  predecessor holds, a move in the join's fixup.  With this look-ahead
  IntMap's union-mix_sn_swap takes 0.42% fewer instructions
  and union-mix_nn and union-mix_nn_swap 0.26% fewer at -O2, and at -O1
  intmap fromAscList 0.82% fewer, fromAscList:fusion 1.11% and intset
  fromAscList:sparse 0.87%.  Measured at the end of the series,
  the look-ahead costs the compiler 0.39% more instructions and 0.09% more
  allocation compiling perf/compiler's T3294 at -O0, and 0.14% more
  allocation compiling !16269's ManyBasicBlocks at -O0; in this commit's
  own figures the method's saving cancels most of it.
  
  raInsn no longer drops a move from one vreg into another, giving
  the destination the source's register, where a jump target of the block
  whose assignment is recorded has the destination in a free register
  other than the source's and another vreg in the source's: the move
  then puts the destination where the target has it, and the jump does
  not have to swap it with that other vreg, as in containers' IntSet
  compare (intset instanceOrd:dense).  Where no target has a vreg
  in the source's register, the move is dropped as before, the jump moving
  the destination on its own edge rather than the move running on every
  path out of the block.
  
  The expected assembly of codeGen/should_gen_asm's
  bytearray-memcpy-unroll and bytearray-memset-unroll names other
  registers now; the instructions and their order are the same.
  
  Simpler forms cost more.  %rbx last for every vreg costs up to 3% more
  instructions in procedures that make C calls.  %r14 first as well,
  wherever no vreg is live across a C call, gains in some loops but costs
  up to 3% more elsewhere, where %r14 is wanted later, for R2 or by a jump
  target's recorded assignment.  Taking the registers a C call preserves
  first for every vreg live across one, ignoring every other write, makes
  fannkuch-redux take 1.3% more instructions: a loop variable live across
  a call elsewhere in the procedure is given %r14 and moves out of R2's
  way at every iteration.
  
  Measured against the parent commit, in instructions: nofib's programs
  take 0.38% fewer (fasta 5.1%, k-nucleotide 4.3%, gen_regexps 3.3%; 0.47%
  at -O1, 0.06% at -O0), none as much as 0.2% more beyond their run-to-run
  noise; fannkuch-redux 0.19% fewer; vector's benchmarks 1.0% fewer
  (nextPermutationBijective 4.4%, findIndexR 3.4%), none more than 0.1%;
  containers' benchmarks 0.66% fewer (set fromAscList:fusion 6.8%, intset
  partition 6.1%, graph buildG 2.2%); megaparsec's benchmarks 0.59% fewer
  (reachOffsetNoLine 6.7%, many 5.6%).  No benchmark's allocation changes
  beyond nofib's run-to-run noise.  The compiler allocates 0.2% more
  compiling perf/compiler's T3294 at -O0, 0.2% more compiling T12707, 0.2%
  more compiling T783, and 0.3% more compiling T9961.  Compiling !16269's
  ManyBasicBlocks at -O1 and -O2, the compiler allocates 0.6% more.
  
  The rises in containers are trades, each with a toggle.  At -O1 IntSet's
  union-common and union-mix take 0.44% to 0.85% more, union-block 0.25%
  to 0.40% and IntMap's union-common 0.14% to 0.51%, and no later commit
  takes them back: union_info loads the subtree field into %rdi rather
  than %rsi, and each of its recursion-call blocks adds a move,
  the partition of the free registers by clobbering writes being tied,
  the field moved into %rsi on two paths while %rsi is written
  on the third; which side wins depends on how the input sets overlap.
  Not counting as clobbered a vreg's own dying-move destinations up
  to three jumps ahead, except for vregs live across a C call, takes them
  back, but makes intset fromAscList:sparse take 2.64% more, map
  fromListWith-desc and its siblings 0.87% to 1.08% more, IntSet's
  and IntMap's symmetricDifference common, mix and block rows 0.30%
  to 0.59% more and Map's union-common_nn 0.49% more (-O2), and costs
  0.27% more compile allocation for T3294 at -O0. map
  fromListWith-desc:fusion takes 0.97% more at -O2: of four
  specialisations of one insertion loop, which share R4 between two
  subtree fields, the order wins three, and the variant that wins
  the fourth makes the other three take 1.0% to 1.1% more.  At -O1
  the fused fromAscList family, intmap lookup_misses and map
  fromList-distinctAsc:fusion take more by R1's place last in the order;
  R1 in its natural place reverts them, but brings back graph buildG's
  2.1% rise of "Prefer the register a later block moves a vreg into where
  it dies" and makes intset folds:dense foldr'_maximum take 5.8% more.
  intset mapMonotonic takes 1.27% more at -O2, the order putting %rsi
  after %rax so that the hot path's reload cannot take %rax; leaving out
  the registers jump targets give other vregs for vregs without
  preferences too fixes it, but makes set alterF:insert:present take 2.4%
  more, alterF:delete:absent 2.7% and map fromAscList:fusion 1.9%. intset
  fromList:randomDups:fusion takes 0.55% more at -O1; R1 in its natural
  place for vregs that die in their block fixes it, but gives back
  folds:dense foldr'_maximum's gain (5.5%) and folds:sparse
  foldr'_maximum's (0.9%).
  
  Assisted-by: Claude Opus 5.5
  
  

• 39dfa21b
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Free every register not live into a newly reached block (GHC #27981)
  
  On the first jump to a block, joinToTargets_first recorded, beside
  the block's assignment, the block's free registers, the source block's
  with those of the vregs not live into the target released, and initBlock
  started the block with them. A real register still allocated at the jump
  and not live into the target, R1 above all where it is allocatable,
  therefore stayed allocated in the target block until the block wrote
  it and that value died: a value the block reloads cannot go back to it,
  and the block's jumps may need fixup moves. initBlock now derives
  the free registers on entry to every block: every allocatable one
  but the real registers live into it and those holding the vregs
  of its recorded assignment, if it has one; a recorded assignment
  no longer carries free registers, and joinToTargets no longer computes
  the registers to release (to_free), nor needs FR. In its reproducer
  the previous commit already removes the fixups, so the reproducer does
  not show this fix alone; here its inline form goes from 14.0 to 13.0
  instructions an element. allocateRealRegs marks the real registers among
  those live into a block allocated, and initBlock takes the procedure's
  initial free registers from RA_Context (rc_initFree) rather than rebuild
  them for each block; runR starts the allocator with them too,
  and with an empty block assignment, register assignment and stack map,
  taking none of them as arguments; joinToTargets_first, left with two
  statements, is inlined by hand at its one call site.
  
  This applies on every target the linear allocator serves; the figures
  below are x86-64's. Measured against the parent commit, in instructions:
  nofib's programs, vector's benchmarks and fannkuch-redux move by no more
  than their noise; containers' benchmarks take 0.03% fewer (tree edges
  1.4%, graph transposeG 1.3% and buildG 1.1%), none more beyond their
  noise, and megaparsec's 0.21% fewer (many 1.2%, sepEndBy 0.9%), none
  more. No benchmark's allocation changes beyond nofib's run-to-run noise.
  The compiler allocates 0.2% less compiling perf/compiler's T3294 at -O0,
  0.8% less compiling T12707, 0.7% less compiling T783, and 1.1% less
  compiling T9961. Compiling !16269's ManyBasicBlocks at -O1 and -O2,
  the compiler allocates 2.5% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 1b94a479
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Write the linear allocator's state only where it changes
  
  releaseRegs, which genRaInsn calls twice for every instruction,
  with the registers the instruction reads for the last time and
  those it writes that die at once, wrote the assignment and the free
  registers back to the allocator's state even where it had no register
  to release; saveClobberedTemps, for every instruction that writes a real
  register, folded over the whole assignment in the monad and wrote
  it back even where no value sat in a clobbered register. Each write
  builds a new RA_State. releaseRegs now returns at once where it has
  nothing to release, and saveClobberedTemps picks the values to save
  by a pure fold, in the order the monadic one took them, and writes
  the state only where there are some. The generated code is the same.
  
  The compiler allocates 2.1% less compiling perf/compiler's T3294 at -O0
  and 0.8% less at -O, 1.5% less compiling T12707 at -O0 and 0.5% less
  at -O, 1.4% less compiling T783 at -O0 and 0.2% less at -O, and 1.9%
  less compiling T9961 at -O0, though less than 0.1% less at -O. Compiling
  !16269's ManyBasicBlocks at -O1 and -O2, the compiler allocates 3.0%
  less.
  
  Assisted-by: Claude Opus 5.5
  
  

• ce5fc4e6
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Find the linear allocator's spill candidates in one fold
  
  Where no register of a vreg's class is free, allocRegsAndSpill_spill
  frees the register of another vreg: the first one that is in a register
  and in a stack slot, else the first one only in a register, among
  those it need not keep. It found them by filtering the whole assignment
  to the vregs in a register, deleting those to keep, listing the rest
  and searching the list twice. It now folds over the assignment once,
  keeping the first vreg of each kind, in the order the list had them.
  The generated code is the same.
  
  The compiler allocates 8.6% less compiling perf/compiler's T3294 at -O0
  and 3.9% less at -O, and 0.5% less compiling T12707 at -O0;
  its allocation compiling T783 and T9961 does not change. Compiling
  !16269's ManyBasicBlocks at -O1 and -O2, the compiler allocates 0.2%
  less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 2390f3fb
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Walk register assignments without listing them
  
  clobberRegs listed the whole assignment, for every instruction
  that writes a real register, to move the vregs that are in a clobbered
  register and in a stack slot to the slot only; it now folds
  over the assignment. joinToTargets_again listed the recorded assignment
  of a jump target and the current one, to compare them ignoring
  the formats; equalIgnoringFormats now compares the two maps themselves.
  The generated code is the same.
  
  The compiler allocates up to 0.07% less compiling perf/compiler's T3294,
  T12707, T783 and T9961 (T9961 at -O0). Compiling !16269's
  ManyBasicBlocks at -O1 and -O2, the compiler allocates 3.2% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 9a9a919c
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Sort a procedure's blocks only where its first block is not first
  
  regAlloc sorted the linear allocator's blocks to keep the procedure's
  first block at the front; it now sorts them only where that block
  is not at the front already. The generated code is the same.
  
  The compiler allocates 0.09% less compiling perf/compiler's T3294
  at -O0, 0.3% less compiling T12707 at -O0 and 0.1% less at -O, 0.3% less
  compiling T783 at -O0 and 0.08% less at -O, and 0.5% less compiling
  T9961 at -O0.
  
  Assisted-by: Claude Opus 5.5
  
  

• 7d7109e3
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Compute the dying registers and the live-in map of liveness strictly
  
  liveness1 left, in each instruction's liveness, the registers read
  for the last time there and those written there that die at once
  as thunks, which the linear allocator forces at every instruction;
  livenessSCCs and livenessBlock likewise left the map of the registers
  live into each block, and each entry, to be computed later. They are now
  computed as the liveness pass goes. The generated code is the same.
  
  The compiler allocates 0.7% less compiling perf/compiler's T3294 at -O0
  and 0.3% less at -O, 0.7% less compiling T12707 at -O0 and 0.2% less
  at -O, 0.8% less compiling T783 at -O0 and 0.2% less at -O, and 0.8%
  less compiling T9961 at -O0.
  
  Assisted-by: Claude Opus 5.5
  
  

• a166f87e
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Skip the address registers x86's mkRU would drop
  
  regUsageOfInstr on x86 and x86-64 added every register an address names
  to an instruction's register lists, and mkRU then filtered out the ones
  the allocators do not manage, such as Sp's %rbp, Hp's %r12 and BaseReg's
  %r13, copying each list that held one: those of every access
  to the stack or the heap. An address's registers that mkRU would drop
  are now left out where they are added. This commit is a subset
  of Sylvain Henry's !16843, whose register usage DSL adds each register,
  an address's included, only where the allocators manage it.
  The generated code is the same.
  
  The compiler allocates 0.8% less compiling perf/compiler's T3294 at -O0
  and 0.3% less at -O, 0.4% less compiling T12707 at -O0 and 0.1% less
  at -O, 0.3% less compiling T783 at -O0, and 0.2% less compiling T9961
  at -O0.
  
  Assisted-by: Claude Opus 5.5
  
  

• 553f7428
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  List a CFG's edges once in block layout
  
  sequenceChain listed the edges of the CFG twice, once for the chains
  it builds and once for the edges left between them; it now lists them
  once. The generated code is the same.
  
  The compiler allocates 0.10% less compiling perf/compiler's T12707
  at -O, 0.07% less compiling T783, and 0.03% less compiling T3294; at -O0
  its allocation does not change. Compiling !16269's ManyBasicBlocks
  at -O1 and -O2, the compiler allocates 0.1% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• e7b0378a
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Build loopInfo's dominator map in one fold
  
  loopInfo's mkDomMap listed every block's dominators as pairs, each
  block's followed by those below it, and made a map of the list. It now
  inserts each block into the map as it walks the dominator tree, a change
  taken from Simon Jakobi's !16269 for GHC #27448; this commit is a subset
  of !16269, which makes the same change to mkDomMap but for the sets,
  below, and also adds the perf test ManyBasicBlocks. The sets stay
  as they were, but for the root's empty one, which goes: each block
  but the root maps to the blocks dominating it, itself included
  and the root left out, where !16269 leaves a block out of its own set;
  that part of !16269 is not taken, because it was found incorrect:
  no self loop would then count as a back edge, the case the commit
  counting self loops as loops fixes. loopInfo runs
  under -fcmm-static-pred, on at -O1 and -O2. The generated code
  is the same.
  
  At -O the compiler allocates 0.2% less compiling perf/compiler's T3294
  and T12707, 3.8% less compiling T783, and less than 0.01% less compiling
  T9961; at -O0, where loopInfo does not run, its allocation moves by less
  than 0.001%. Compiling !16269's ManyBasicBlocks, the compiler allocates
  27.4% less at -O1 and 27.3% less at -O2.
  
  Assisted-by: Claude Opus 5.5
  
  

• bdca0e5e
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Build no lists of results in calcFreqs
  
  calcFreqs, which static prediction runs for every procedure, built
  a list of results for each block's out-edges (forM in calcOutFreqs) and,
  for each block's predecessors, a list of Bools to test for irreducible
  flow and a list of probabilities to sum. It now uses forM_, anyM
  and a left fold from 0, which adds the probabilities in sum's order,
  so that the frequencies are the same, and so is the generated code.
  
  At -O the compiler allocates up to 0.10% less compiling perf/compiler's
  T3294, T12707, T783 and T9961 (T12707); at -O0, where static prediction
  is off, its allocation does not change. Compiling !16269's
  ManyBasicBlocks at -O1 and -O2, the compiler allocates 0.3% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 830b15d4
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Give back edges no bonus where static prediction estimates the weights
  
  optHsPatterns raised every back edge of positive weight by backEdgeBonus
  (increaseBackEdgeWeight), after a depth-first search for them;
  under -fcmm-static-pred, on at -O1 and -O2, staticPredCfg then replaces
  the weights of the branches its heuristics cover with its predictions
  and estimates frequencies from them. The bonus is now left out there:
  increaseBackEdgeWeight moves out of optHsPatterns, and optimizeCFG calls
  it only where static prediction does not follow. The bonus counted only
  at the branches static prediction leaves alone, a heap or stack check's
  and those whose targets are all back edges, and at a two-way branch back
  into the procedure's entry, whose weights static prediction starts from,
  loopInfo counting no edge into the entry a back edge. Leaving it out
  of those as well changed no code measured. The generated code
  is the same on every program measured: perf/compiler's T3294, T12707,
  T783 and T9961 at -O0 and -O, and nofib's programs at -O2 and -O1, whose
  objects are identical.
  
  At -O the compiler allocates up to 0.15% less compiling perf/compiler's
  T3294, T12707, T783 and T9961 (T783); at -O0, where static prediction
  is off, its allocation does not change. Compiling !16269's
  ManyBasicBlocks at -O1 and -O2, the compiler allocates 0.4% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 8259e69f
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  In sccBlocks, look blocks up in the CFG, not in a set of them
  
  sccBlocks, in GHC.CmmToAsm.Reg.Liveness, built a set of every block
  of the CFG, which holds only reachable blocks, to keep the procedure's
  blocks that are in it; it now looks each block up in the CFG itself.
  The generated code is the same.
  
  The compiler allocates up to 0.24% less compiling perf/compiler's T3294,
  T12707, T783 and T9961 at -O0 (T783), and up to 0.06% less at -O (T783).
  Compiling !16269's ManyBasicBlocks at -O1 and -O2, the compiler
  allocates 0.1% less.
  
  Assisted-by: Claude Opus 5.5
  
  

• 67172797
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Inline x86's takeRegRegMoveInstr
  
  takeRegRegMoveInstr, which the register allocators and the liveness pass
  call on every instruction they look for a register-to-register move in,
  built a Just and a pair for each move it found. Most callers take both
  apart at once. Inlined, it builds neither where its caller takes them
  apart. The generated code is the same.
  
  The compiler allocates up to 0.12% less compiling perf/compiler's T3294,
  T12707, T783 and T9961 at -O0 (T9961); at -O its allocation moves
  by 0.01% or less.
  
  Assisted-by: Claude Opus 5.5
  
  

• d3389eb8
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Swap the registers of a cyclic join fixup where one instruction can
  
  Where a jump's target has a recorded assignment, joinToTargets moves
  the vregs into it, and where the moves form a cycle, handleComponent
  spilled one source to its stack slot and reloaded it
  into its destination after the other moves: a store and a load,
  and a stack slot the vreg may not have had. The Instruction class now
  has mkRegRegSwapInstr, which gives an instruction that swaps two
  registers of a format where there is one, and by default Nothing; on x86
  and x86-64 it is xchg for the general-purpose registers. handleComponent
  now swaps a cycle's first source with its destination where it can,
  so that a cycle of n moves takes n - 1 swaps; it spills as before
  otherwise, as for floating-point and vector registers. An xchg is two
  micro-ops on Zen 3, but breaking a cycle through a free register
  instead, with three movs, ran in as many CPU cycles there and took more
  instructions (megaparsec's benchmarks 0.114% more instructions at -O2,
  skipManyTill 2.1% more); breaking floating-point cycles through a free
  register changed nothing measured, the register cycles it would convert
  occurring only a few times in all the suites. makeRegMovementGraph's
  comment that cyclic components seem to occur only very rarely is gone:
  with master's allocator, orthotope's $w$s$wequalT1 breaks 39 register
  cycles through stack slots and its $w$s$w$ccompare1 59.
  
  The compiler's allocation compiling perf/compiler's T3294, T12707, T783
  and T9961 moves by less than 0.01% at -O0 and -O. Of nofib's programs
  only puzzle moves by more than 0.2% in instructions: it runs 0.5% fewer,
  and 0.7% fewer cycles. containers' sequence adjust.10, adjust.100
  and adjust.1000 run 0.58%, 0.30% and 0.16% fewer instructions and intmap
  fromListWith:randomDups:fusion 0.43% fewer, their cycles moving within
  the noise; vector's benchmarks move by less than 0.01%, and megaparsec's
  run 0.73% fewer (skipManyTill 3.9%, endBy1 2.3%), none more.
  In megaparsec's count, sepBy and sepEndBy and in vector's quickhull,
  cycles through stack slots become xchg instructions.
  
  Assisted-by: Claude Opus 5.5
  
  

• cc643248
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Store no value into the slot holding it at a join
  
  expandNode turned a vreg that is InBoth in the same stack slot at both
  ends of a join into a store into that slot, beside a register move where
  the registers differ and alone where they do not, though the slot
  already holds the value.  Such a vreg now needs at most the move.
  
  Measured on x86-64 with this commit placed after the stack layout
  commits of an earlier form of the series, against that form,
  in instructions: the change removes stores and nothing else. vector's
  benchmarks take 0.27% fewer at -O2 (leaffix 5.26%, rootfix 2.82%)
  and megaparsec's manyTill 1.45% to 1.49% fewer at -O2, two stores gone
  from one join fixup; nofib's programs move by less than 0.2% at -O2, -O1
  and -O0, and no benchmark of containers, vector or megaparsec rises
  beyond its noise.  The compiler's allocation compiling perf/compiler's
  T3294, T12707, T783 and T9961 and !16269's ManyBasicBlocks moves
  by 0.01% at most.
  
  Assisted-by: Claude Opus 5.5
  
  

• 9680269b
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Predict branches into loop heads that only a heap or stack check makes
  
  staticBranchPrediction's loop exit heuristic, lehPredicts, says nothing
  about a branch into a loop head. A heap or stack check that fails calls
  the garbage collector, which returns to a block that jumps back
  to the check, and loopInfo counts that cycle as a loop; so in a loop
  that holds such a check, the check's block is a loop head,
  and the heuristic said nothing about the test that stays in the loop
  by branching to it. loopHeads now leaves out a head whose back edges all
  leave a block of coldBlocks, and the loop levels the heuristic compares
  count only the loops left: counting the others too would put a block
  that heads only such a cycle a level deeper than its siblings,
  so that the heuristic would predict any branch into it. The set
  is coldBlocks, not checkFailures: static prediction runs after register
  allocation, so the cycle can close from a block the allocator put after
  one that follows the failed check, which coldBlocks holds
  and checkFailures does not. loopInfo no longer counts loop levels
  (liLevels), which staticBranchPrediction now counts over the loops left,
  and loopLevels, which had no caller, goes. A back edge leaving
  a continuation that a call returns to as well as the garbage collector
  counts the same, so a loop closed through such a call loses its head
  too; telling the two apart moved no figure measured.
  
  Where it changes the layout, this saves cycles, not instructions:
  with the stay side predicted, the layout can let it fall through,
  a taken jump fewer an iteration, and a conditional jump is one
  instruction whether taken or not. Before the levels were limited,
  lookupGE3's loop in containers' lookupge-map took one jump an iteration
  instead of two, the tag test's jump backward in the layout to the heap
  check and then one out of the comparison, and GE Twan ran 2% to 11%
  fewer cycles at no more than 0.03% more instructions; limiting them
  leaves that loop's jumps as they were.
  
  Measured against the parent commit, on x86-64: the instructions
  of nofib's programs and of containers', vector's and megaparsec's
  benchmarks move by less than 0.01% in geometric mean. intset folds:dense
  foldl'_maximum takes 6.5% fewer, the fixup block before its loop's head
  now falling into the head. In cycles nofib's programs fell 0.01%
  in geometric mean with the heads left out and rose 0.3% with the levels
  limited, single programs moving by up to 12% either way where unchanged
  code lands elsewhere: gcd's 4.7% rise comes from its bignum code,
  unchanged but placed 80 bytes later, and hartel/listcopy's 12% from code
  that a grown function moved. The compiler allocates 0.12% less compiling
  perf/compiler's T783 at -O, 0.06% less compiling T12707, and less
  than 0.01% less compiling T3294 and T9961; at -O0 its allocation moves
  by less than 0.001%.
  
  Assisted-by: Claude Opus 5.5
  
  

• ad1c15db
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  NCG: invert floating-point conditional branches too
  
  invertCondBranches turns a block's `jcc next; jmp other`
  into `jncc other` only where the condition comes from an integer
  comparison. maybeInvertCond complements the condition on the flags,
  which nothing between the two jumps changes, so the swapped jumps take
  the same path for every outcome of a floating-point comparison too,
  an unordered one included, in each shape genCondBranch' emits for one.
  
  Of the 173 such pairs nofib's objects keep at -O2, 166 follow a ucomisd
  and go. mandel2 runs 2.6% fewer instructions and smallpt 0.7% fewer;
  no other program whose code changes moves by 0.1%.
  
  Assisted-by: Claude Opus 5.5
  
  

• e012fcfe
  by Mikolaj Konarski at 2026-11-03T22:23:57+01:00

  Drop the assignments that only a discarded assignment read
  
  Cmm sinking computes liveness once, before its walk, so where the walk
  discards an assignment that nothing reads, such as a copy, it keeps
  the assignments that only that one read (GHC #8327). cmmSink now reports
  whether its walk discarded one that reads a register, and if it did,
  dropDeadAssignments drops the assignments to local registers whose
  values nothing needs, found in one pass by liveness in which
  an assignment makes the registers it reads live only where its own
  register is live. Nothing is folded or inlined again.
  
  A second sinking pass over every procedure, its liveness recomputed,
  drops them as well, but in a trial it made the compiler allocate 60%
  more compiling perf/compiler's T3294 at -O, and its constant folding,
  which in that trial rewrote (a - b) + c to a + (c - b) whatever b and c
  were, cost containers' elemAt benchmarks up to 2.4% more instructions.
  Recomputing liveness until no assignment is dead drops them too,
  but takes a pass for each link of a chain of assignments each read only
  by the next: on a procedure with a chain of 400, the compiler allocated
  9.2 times what master's does.
  
  The test, T8327, is a Cmm loop that assigns a constant read only
  by a copy that nothing reads; the constant must not appear in its Cmm.
  With the parent commit's compiler it does.
  
  Measured against the parent commit, on x86-64: vector's benchmarks
  at -O1 run 2.0% fewer instructions (sum[base] 14.3%, map[base] 9.1%,
  spectral 4.3%, generateIO 4.0%), none more by 0.01%; in sum[base]'s
  loop, the address of the SPEC token that vector's stream fusion passes
  from one iteration to the next was loaded at each iteration, read only
  by an assignment that sinking discarded. At -O2 none moves by more
  than 0.03%, and those that move most have the same code. containers'
  benchmarks at -O2 run up to 9.5% fewer (nubOrd noFusion_repeat 9.5%,
  issue1202_repeat 4.7%, set alterF:insert:present 2.9%, lookupge-map GE
  split 0.6%), none more; at -O1 only Data.Sequence's code changes,
  and no benchmark moves beyond its noise. megaparsec's benchmarks at -O2
  run up to 1.0% fewer (skipManyTill 1.0%, manyTill 0.7%), none more,
  and at -O1 none moves. Of nofib's programs only rewrite's objects
  change, and no program moves by as much as 0.2%; fannkuch-redux does
  not change. The compiler allocates 0.03% more compiling perf/compiler's
  T3294 at -O, 0.09% more compiling T12707 and T783, 0.04% more compiling
  T9961, 0.1% more compiling !16269's ManyBasicBlocks at -O1 and -O2,
  and 0.1% more over nofib's compilations.
  
  Assisted-by: Claude Opus 5.5
  
  

• cadf226e
  by Mikolaj Konarski at 2026-11-03T22:23:58+01:00

  Keep Sp put across loops and tag tests in stack layout
  
  Stack layout gives a block the stack map of the first
  of its predecessors it visits, and every later edge into the block gets
  a fixup. It sets a diamond's frame (Note [diamond proc point]) up before
  the tag test, trimmed to the variables live in the continuation,
  and the continuation reloads them all, on the evaluated path too.
  So in a loop whose body evaluates a variable, every iteration moves Sp
  twice and stores the loop's invariants again, and where the variable
  was evaluated already, it reloads registers that still hold their
  values.
  
  These changes to GHC.Cmm.LayoutStack keep Sp and the slots put:
  
    * a loop head takes the stack map its back edges have in common,
      by a second layout run where that pays, and the edge into the loop
      pays the difference once (Note [Loop head stack maps]); a back edge
      reached only through an unlikely branch proposes nothing, and a head
      every cycle through which makes a non-tail call to its own procedure
      is left alone, its loop turning about once an entry (nofib's tak,
      containers' foldrWithKey');
    * a loop head that takes no such map, its back edges differing
      in depth or needing no fixup, gets in the second run the depth
      of the deepest continuation in its loop, with the loop's invariants
      in the slots that continuation's frame gives them: a call returning
      into the loop keeps that depth, where it moved Sp twice
      an iteration, down at the call and up at the fixup on the edge where
      its return path joins a path that made no call, and the edge
      into the loop pays the Sp move and the invariants' stores once (Note
      [Reserved frames in loops]);
    * the continuation becomes its reloads and a jump to its body, which
      the evaluated path jumps to directly, where proc points
      are not split and the reloads this adds at earlier proc points stay
      at most two a diamond, or else for the diamonds whose tag test
      follows no proc point whose reloads grow (Note [Tagged path skips
      the reloads]); on a loop holding at most sixteen diamonds'
      continuations the body takes every variable in its register but one
      live across an inner loop that does not read it, and elsewhere only
      those stored on the call's edge, reloading the rest itself where
      they are used;
    * the return address is stored on the call's edge only, where the call
      is the only block returning to the continuation;
    * a variable that at most one later call needs in a slot is stored
      on the call's edge only too, that later call storing it on its own
      path (Note [Tagged path skips the stores]);
    * a diamond's frame keeps the stack's depth, its dead slots left
      as holes (Note [Diamond frames keep their depth]);
    * the frame a call into a diamond's continuation pushes is trimmed
      to its live variables after layout, by a pass of its own, where,
      among other conditions, proc points are not split and either
      the procedure is called by a thunk of its Cmm group, as a lazy
      list's producer is by the thunk of the list's tail, or the holes
      are at least half the live words and the procedure is a thunk
      or the continuation is on no loop: the call can evaluate a thunk
      that leads back to such a frame, and each level of the recursion
      would hold the holes (nofib's primes and multiplier); each call
      returning there moves Sp up to the trimmed frame, the continuation
      moves it back down, and the tagged path moves it nowhere (the same
      Note).
  
  The reservation leaves these cases out, each having paid more
  than it saved:
  
    * a continuation reached only through an unlikely branch, which
      reserves nothing: a heap check's GC call returns into many a loop
      that makes no other call, whose every entry and exit would pay
      for a frame only that rare path uses (megaparsec's word32be,
      containers' lookupGE);
    * a loop that only permutes the variables live at its head,
      as integerAdd's swap of its arguments, which turns a few times
      an entry;
    * a loop making a non-tail call to its own procedure, each level
      of the recursion then holding the reserved frame, a stack
      the garbage collector scans (containers' foldl' over a line-shaped
      tree);
    * a loop holding a head seeded from its back edges, whose seed expects
      its variables in other slots than the reserved frame gives them
      (nofib's puzzle, six register swaps at a join).
  
  A variable that the continuation's code saves at the first call
  it reaches without a conditional branch, within eight blocks, neither
  reading nor redefining it on the way, is still stored before the test:
  the tagged path would store it there anyway, and the call's path would
  reload it at the continuation to store it again (nofib's fasta).
  In a procedure that makes a non-tail call of itself, and for a diamond
  on a cycle of blocks, cold ones left out, that makes no non-tail call
  into the procedure's recursion (its strongly connected component
  in its Cmm group's call graph, computed once a group
  in GHC.Cmm.Pipeline), those stores all stay only where the call's frame,
  set up there, is no deeper with them all, and otherwise each only where
  that frame has its variable in the slot the diamond's frame gives it:
  otherwise the slot would deepen every level of the recursion
  (containers' PostOrder folds), or a loop's seeded frame would be set up
  and dropped every iteration (containers' intset insert and sequence
  update.10).
  
  tagSkip, which splits the continuations, checks the limit of two reloads
  a diamond first against a bound read off the graph, each diamond's
  variables taken in registers times the proc points whose regions hold
  its tag test, and runs its analyses only where the bound exceeds
  the limit; there it computes each block's live-in and reads once for all
  continuations, its loop rule (across) tests only the frame's variables,
  and the continuations on one loop share each block's successors in it.
  laterSaves searches only as far as each query needs in a procedure
  without loops, across numbers each loop's blocks and works on bit sets,
  and liftFrames and tagSkip no longer walk every frame.
  In GHC.Cmm.Info.Build, cafAnal takes a jump into a split body
  as a reference to its continuation's info label: otherwise each block's
  set gathered every later continuation, at a cost growing with the square
  of a procedure's chain of evaluations. None of this changes
  the generated code.
  
  Layout joins the block on a call's edge to the call's block where it
  ends, where the call has no other way in and the procedure has a
  diamond: unjoined, each tag test adds a block to the maps the later
  passes keep of blocks, and at -O0, where no later pass joins blocks, a
  jump.
  
  Two tests in codeGen/should_compile check the assembly for a return
  address stored below Sp, which each stored before this commit:
  StackLayoutTagLoop, a loop evaluating each element in a diamond,
  and StackLayoutCallLoop, a loop calling a function on one of its paths.
  
  Taking the variables in registers at the join is a trade: containers'
  set foldMap_traverseSum takes 3.77% more instructions at -O1, map's
  fromSetA inner rows 0.43% to 0.45% more and intmap's fromSetA rows 0.32%
  and 0.13% more, the split continuation's body moving its variables
  between registers at the join where the parent's code used a memory
  operand. Its toggle is Note [Tagged path skips the reloads]: the body
  reading the variables from their slots instead makes nofib's compress
  take 6.8% more instructions and queens 6.1% more.
  
  Taking them in registers only on loops holding at most sixteen
  continuations is a trade too: nofib's para takes 0.27% more instructions
  at -O1, by one loop holding more, where taking them in registers saves
  reloads and register moves at -O1 and costs reloads at -O2, nearly every
  diamond there taking its call path. Lifting the limit reverts it,
  but makes para take 0.50% more at -O2 and puzzle 4.38% more at -O1
  and 2.23% more at -O2.
  
  Storing on the call's edge only a variable that one later call needs
  is a trade: at -O0 nofib's tak, mandel2, life, rfib, fasta and others
  take more instructions, at -O1 multiplier, and at -O2 atom, ansi
  and life, the path through a diamond's call paying a jump to the split
  body and a register move more; the diamonds that lose and
  those that gain differ only in their callers' arguments, which stack
  layout cannot see. Storing every variable before the test instead makes
  nofib's programs take 0.91% and 0.98% more instructions and containers'
  benchmarks 2.3% and 2.7% more, at -O2 and -O1, and megaparsec's 3.4%
  more at -O2.
  
  Reserving a loop's frame is a trade: nofib's boyer2 takes 0.21% more
  instructions, a loop's entry moving Sp and shuffling registers at each
  iteration for a call path run less than half as often, and containers'
  tree PostOrder.Foldable maximum 1.35% more at n=1000 and 0.39% more
  at n=1000000; a further left-out case, for loops calling a procedure
  private to the module, reverts them, but also gives back the gains
  of nofib's sched (0.9%), transform (0.4%) and parstof (0.3%).
  megaparsec's reachOffset-1000-1000 takes 1758 instructions
  with or without that case, a few more than without the reservation:
  the reservation's own trade.
  
  The compile cost is that of these analyses: against the parent commit
  the compiler allocates 2.81% more compiling perf/compiler's T12707
  at -O0 and 1.63% more compiling T3294 at -O0, and 2.34% more
  over nofib's compilations. Compiling !16269's ManyBasicBlocks,
  the compiler's allocation: FIGURES FROM THE REBUILD.
  
  FIGURES FROM THE REBUILD
  
  Metric Increase:
      T18304
  
  Assisted-by: Claude Opus 5.5
  
  

• 0e9fe866
  by Mikolaj Konarski at 2026-11-03T22:23:58+01:00

  Jump conditionally to a likely false comparison's false target
  
  genCondBranch jumps to the true target conditionally and to the false
  one after, and ignores cml_likely.  Where the layout makes either target
  a fall-through, invertCondBranches and dropJumps leave one conditional
  jump whichever order it emits; where neither jump falls through,
  the conditional jump is the shorter way to its target,
  so invertCondBranches now swaps the two jumps of an integer comparison
  likely false whose true target does not come next.  After layout rather
  than before genCondBranch: swapped there, every heap and stack check's
  jumps were swapped and swapped back by invertCondBranches, costing up
  to 0.29% more instructions compiling at -O0. invert examines a block's
  last two instructions once and chooses between the old rule and the new
  one.
  
  Measured on x86-64 with this commit placed at the end of an earlier form
  of the series, against that end, in instructions: containers' IntMap
  fromSet and fromSetA rows take 0.34% to 0.46% fewer at -O2 and fromSet
  0.36% fewer at -O1, beyond the leftover jump "Drop jumps over blocks
  dropJumps empties" removes there; no benchmark rises beyond its noise,
  and the compiler allocates less compiling each of perf/compiler's T3294,
  T12707, T783 and T9961 and !16269's ManyBasicBlocks, at every level
  measured.
  
  Assisted-by: Claude Opus 5.5
  
  

• aa546c8c
  by Mikolaj Konarski at 2026-11-03T22:23:58+01:00

  Estimate block frequencies once per procedure before linear allocation
  
  blockFrequencies in GHC.CmmToAsm.CFG makes mkGlobalWeights' estimate
  of how often each block runs, for the linear allocator, from the native
  CFG before allocation, under -fcmm-static-pred as the layout's estimate
  is: static prediction's edge probabilities (the two-way rule factored
  out of staticBranchPrediction as predictBranch, shared, given
  the procedure's tagRegisters as the layout's estimate is) and calcFreqs'
  fixpoint, with loops found by one depth-first search and the whole
  computation in two arrays. CmmToAsm passes Linear.regAlloc the estimate
  from a given entry, bound strictly so that at -O0 it is the static
  noBlockFreqs and no thunk a procedure; regAlloc computes and forces it,
  and the next commit uses it.
  
  Assisted-by: Claude Opus 5.5
  
  

• 80f50ceb
  by Mikolaj Konarski at 2026-11-03T22:23:58+01:00

  Allocate hotter SCCs first, the procedure's first block before them
  
  Where block frequencies are estimated, linearRA_SCCs allocates the SCCs
  hotter first among those it can allocate (hotFirst, an order computed
  before allocation from the jumps), the procedure's first block before
  any other and another entry as hot as the hottest of itself
  and the blocks it jumps to, an SCC's heat compared in factors of 1.2
  with ties to the earlier in dependency order, and sets aside an entry
  other than the first block while a block it jumps to, not yet reached,
  runs more than 1.2 times as often as the entry; where nothing can
  be allocated, the entry set aside that the estimate calls hottest goes
  next. This replaces the deferral of the blocks the garbage collector
  returns to and of a continuation entering a call-free loop, which stay
  where there is no estimate (-O0, other targets). The first block first
  keeps a loop calling itself on the argument registers (Data.Tree's
  and Data.Map's folds); the factor leaves to dependency order what static
  prediction's 50/50 on tag tests makes of the paths around an evaluation
  (Data.IntSet's fromAscList loop); the hottest entry set aside first
  gives a join of two continuations, both waiting, the hotter's registers
  (Data.IntMap's mapKeysMonotonic and Data.IntSet's fromList at -O1);
  an entry ranked by its hottest jump target, not above every other SCC,
  keeps a continuation before the path into the block it jumps to (nofib's
  fannkuch-redux at -O1) without putting colder continuations before
  a hotter one (Data.IntSet's mapMonotonic at -O2). hotFirst is NOINLINE,
  so that its local thunks are not allocated for every procedure at -O0,
  where it is not called.
  
  Measured on x86-64 with this commit and the previous one placed
  at the end of an earlier form of the series, against that end,
  in instructions: nofib's programs take 0.30% fewer at -O2, 0.29% at -O1
  and 0.53% at -O0, through the libraries' code, and at -O2 and -O1
  containers' benchmarks 0.39% and 0.49% fewer, vector's 0.38% and 0.73%
  and megaparsec's 0.14% and 0.38%.
  
  The order is a trade, its toggle the order itself (hotFirst's guard
  in linearRA_SCCs). In loops closed through a call, which the estimate
  rates at a trip multiplier far below the run's, containers' map
  fromList-distinctAsc:fusion takes 2.3% more, set
  fromDistinctDescList:fusion 1.9% more and intset fromRange:small 1.4%
  more, and nofib's scs 0.65% more. Elsewhere containers' nubOrd
  strings_noFusion_distinct takes 1.35% more, intset map:asc,
  and mapMonotonic at -O1, about 1.0% to 1.3% more, intmap
  fromList:asc:fusion 0.96% more, and at -O1 intset fromAscList
  and fromAscList:sparse 2.7% and 2.0% more and set alterF:insert:present
  0.53% more; nofib's smallpt takes 0.53% more, digits-of-e2 0.28% more
  and fannkuch-redux 0.33% more at -O1.
  
  Narrower toggles each revert one row at a cost. Making a cyclic SCC
  that holds an entry not pushed at the start wait for a jump to reach
  it reverts graph buildG's 0.92%, but makes intmap lookup_mixed take 5.1%
  more. Letting an entry wait only while its target, not yet reached, has
  another predecessor not yet allocated that runs over 1.2 times as often
  as the entry reverts nofib's puzzle, 0.38% more, but gives back
  containers' tree fold1 gains. Setting no entry aside reverts
  megaparsec's choice, 1.8% and 1.2% more at -O2 and -O1, but makes
  megaparsec's benchmarks take 3.0% and 1.3% more. Ranking every entry
  above the other SCCs, rather than by its hottest jump target, reverts
  map alterF's lookup present, 0.79% and 0.39% more at -O2 and -O1,
  but gives back the gains of intset mapMonotonic at -O2 and
  of the spanAntitone rows, and adds to scs's rise.
  
  The estimate and the order are the compile cost: the compiler allocates
  at most 0.05% more at -O0 (T9961) and 0.12% more at -O and -O2 (T12707
  at -O) compiling perf/compiler's T3294, T12707, T783 and T9961,
  and a stage-1 compiler runs up to 0.39% more instructions (T783 at -O).
  
  Assisted-by: Claude Opus 5.5
  
  

• dd425481
  by Mikolaj Konarski at 2026-11-03T22:23:58+01:00

  Propagate wide move destinations back, preferring the target's register
  
  The last preference of "Prefer the register a later block moves a vreg
  into where it dies", a vreg's wide destination, now reaches back along
  moves: wideMoveDests also gives a vreg moved where it dies, in a warm
  block, into a vreg that has a wide destination, that destination, up
  to four moves back, and the walk of the blocks checks it as it checks
  the others. A vreg given a destination so first takes the first-used
  register of the vreg it is moved into, the claims test skipped,
  as that vreg, dead, still claims its register: given the destination
  itself, a closure moved into a join's vreg took the register that vreg
  is moved into later, not the one it has at the join, and every path
  into the join ended in a move (containers' map fromListWith-asc, 1.26%
  more at -O1). Where a procedure has no candidate the propagation returns
  at once, and it shares its list of moves with the walk.
  
  In containers' tree PostOrder foldl'_sum a loop's carry is now computed
  in R2's %r14, where the recursive call takes it, rather than in another
  register moved there and back. Measured on x86-64 with this commit
  placed at the end of an earlier form of the series, against that end,
  in instructions: vector's maximumOn takes 15.4% fewer, containers' tree
  PostOrder folds 4.3% to 8.1% fewer, nofib's k-nucleotide 1.67% fewer
  and megaparsec's word32be and word32le about 1% fewer.
  
  The propagation is a trade, its toggle propagating along no move, which
  reverts every gain with the rises: nofib's digits-of-e2 takes 0.32%
  more, a reload taking the propagated register before the join it feeds
  is assigned, containers' graph bcc rows up to 0.37% more at -O2 and map
  fromListWithKey-desc 0.065% more. The compiler allocates at most 0.09%
  more, compiling !16269's ManyBasicBlocks at -O0.
  
  Assisted-by: Claude Opus 5.5
  
  

• b7fd254c
  by Mikolaj Konarski at 2026-11-03T22:23:58+01:00

  Give a vreg the register a recorded join wants it in
  
  Where a register is free for a vreg but a recorded jump target's
  assignment wants the vreg in another one, held by a vreg
  that no instruction left in the block reads and that the recorded jump
  targets hold in its slot, allocRegsAndSpill_spill now spills the holder,
  a store that jump would need anyway and none where the holder is
  in its slot already, and gives the vreg its register in place
  of the free one. The test uses the position of each instruction
  in its block and the block's last reads of the vregs live out of it,
  built where the test consults them.
  
  Measured on x86-64 with this commit placed at the end of an earlier form
  of the series, against that end, in instructions: megaparsec's
  benchmarks take 0.32% fewer at -O2 and 0.39% fewer at -O1 (endBy1 2.3%
  to 2.6%, sepBy, sepBy1 and count about 2%) and nofib's puzzle 0.7%
  fewer, no benchmark taking more. The compiler allocates 0.11% to 0.15%
  more compiling at -O0.
  
  Assisted-by: Claude Opus 5.5
  
  

• 537f45a3
  by Mikolaj Konarski at 2026-11-03T22:23:58+01:00

  Spill a vreg its block reads no more
  
  Of the vregs in both a register and their slot, else of those
  in a register only, allocRegsAndSpill_spill evicts the first
  that no instruction left in the block reads, else the first, except
  that a vreg live into a jump target with no recorded assignment
  that another block jumps to as well counts as read again where neither
  the block nor that target is in a cycle. Evicted, such a vreg would
  be in its slot in the assignment the block records for the join,
  so that every later jump there would store it and the code after
  the join reload it: in megaparsec's someTill the cold paths of a UTF-8
  decoder, allocated before the hot one, so cost a store and a reload
  an element. Where the block or that target is in a loop, as a loop's
  head is, the eviction stands: there it keeps a register free
  for the loop. The victim is sought in one fold over the assignment,
  and only where a vreg of the evicted register class is live out
  of the block, the previous choice standing elsewhere; the map of last
  reads is built only where it is consulted, and a procedure's joins
  outside cycles once, where an eviction first consults them.
  
  Measured on x86-64 with this commit and the previous one placed
  at the end of an earlier form of the series, against that end,
  in instructions, the rows the previous commit leaves alone: vector's
  awshcc takes 1.9% fewer, tridiag 1.7% and quickhull 1.0%, containers'
  IntSet and IntMap union and symmetricDifference benchmarks fall, nofib's
  dom-lt takes 0.64% fewer and scs 0.45%, and megaparsec's string' 2.3%
  fewer, no benchmark taking more beyond its noise. With the previous
  commit the compiler allocates 0.13% more compiling perf/compiler's T3294
  at -O0, and compiling !16269's ManyBasicBlocks it runs 0.5% more
  instructions and allocates 0.4% more, about 0.2 and 0.3 points of them
  this commit's set of a procedure's joins outside cycles.
  
  Assisted-by: Claude Opus 5.5
  
  

• 8817aacb
  by Mikolaj Konarski at 2026-11-03T22:23:58+01:00

  Copy small loop heads over the jumps to them before block layout
  
  Block layout lets one edge into a loop head fall through and makes
  the others jump: the loop's entry once a run, every other back edge once
  an iteration. copyLoopHeads, a new NcgImpl method that x86-64 implements
  in GHC.CmmToAsm.X86.CodeGen and that cmmNativeGen runs between
  optimizeCFG and sequenceTop where the chain layout follows, copies
  a loop head of at most six instructions and a conditional branch
  over the jumps to it, after register allocation: a block whose one
  successor is the head, and which ends in a jump to it, ends
  in the head's instructions instead and goes straight on to the head's
  successors, whose edges it takes in the CFG, their weights shared out
  in proportion to the weight of the jump it replaces. A copy
  into the loop's entry saves the jump into the loop; a copy into a back
  edge's source rotates the loop for that edge. Note [Copying loop heads];
  Note [CFG based code layout] lists the new step.
  
  A loop head is a target of a back edge of static prediction's loops,
  which optimizeCFG now returns with the weights (mkGlobalWeightsWith
  returns loopInfo's back edges too), or of findBackEdges' where static
  prediction does not run. The jump that layout would let fall through
  takes no copy: of the jumps to the head, the one ranked first
  by the weights sequenceChain ranks edges by, a back edge raised
  as preferBackEdges raises it, where it outranks every other edge in.
  That jump's CFG weight becomes the raised one, since the copies can take
  away the entry edges preferBackEdges raises it above, and the head's
  out-edges keep their weights, so that the head keeps the loop's body
  after it where static prediction rates the loop's back edge below
  its entry. A block that follows a failed heap or stack check takes
  no copy.
  
  Measured against the parent commit, in instructions, with no benchmark
  of the battery rising by more than its noise: at -O2 nofib's programs
  take 0.20% fewer (fannkuch-redux 2.1%, knights 1.3%, eff/CSD 1.0%,
  digits-of-e1 1.0%), containers' benchmarks 0.43% fewer (intmap
  lookup_half 6.9%, lookup_most 5.2%, lookup_hits 5.1%, intset member
  3.4%, nubInt issue1202_repeat 3.3%), megaparsec's 0.31% fewer (string'
  1.2%, skipManyTill 1.0%) and vector's 1.20% fewer (nextPermutation 5.1%,
  nextPermutationBijective 4.3%, hybcc 1.0%); at -O1 nofib's 0.18% fewer
  (fannkuch-redux 1.9%), containers' 0.52%, megaparsec's 0.33%
  (reachOffsetNoLine 1.6%, reachOffset 1.3%) and vector's 0.93% (leaffix
  0.6%, awshcc 0.6%); at -O0, where it does not run, nofib's 0.12% fewer,
  through the libraries' code. This takes back the trades of the commit
  that lets a loop's back edge outrank its entry: IntSet's difference
  and intersection benchmarks take 0.68% fewer instructions than
  at the parent at -O2 and 1.17% fewer at -O1, nubInt's noFusion_repeat
  2.4% fewer, megaparsec's reachOffset at -O1 1.3% fewer; and vector's
  awshcc at -O1, whose loop's two back edges both jumped, executes 78M
  fewer jumps a call in leaffix, the 1.5M of one of those back edges among
  them. Code grows: nofib's objects' text by 0.68% at -O2 and 0.54%
  at -O1, the stage-2 compiler's by 0.75%. The compiler allocates up
  to 0.14% more compiling perf/compiler's T9961 at -O and 0.12% more
  for T783; with no copying at -O0, up to 0.06% more, for passing the back
  edges on.
  
  Each rule that picks the jump kept took back rises of a version without
  it, measured from scratch or with the stage-1 compiler: copying every
  jump made the loop of two blocks in nofib's spectral-norm a block
  branching to itself, 2.9% more; keeping the heaviest jump by raw weight
  copied the one layout let fall through, in intmap's foldMap_elem (2.3%
  more), intset's fromAscList (3.4%) and base's eqString (nofib's expert
  0.26%); letting the head's out-edges lose the copies' weights gave
  intset's fromAscList's body to the copy of its entry, and leaving
  the kept jump's weight as it was cost nofib's mkhprog 0.55%. The bound
  of six instructions: at four, nubInt's issue1202_repeat keeps a third
  of its gain; at eight, no target row moved. Not taken: a block ending
  in a conditional branch and a jump to the head copying it too, which
  moved nothing in nofib; and a second pass, its back edges found again
  by findBackEdges, which cost ManyBasicBlocks 0.5% more compile
  allocation and gained no more than the rules above.
  
  Assisted-by: Claude Opus 5.5
  
  

• 04b5a1c0
  by Mikolaj Konarski at 2026-11-03T22:23:58+01:00

  Walk liveness first over the instructions as the code generator gives
  
  natCmmTopToLive wrapped every instruction as LiveInstr (Instr i)
  Nothing, in a list of its own, which the first liveness walk dropped
  at once for a LiveInstr carrying the liveness. Now natCmmTopToLive
  returns the procedure's SCCs of NatBasicBlocks, and the walk takes
  an accessor giving each element's InstrSR: Instr on the first walk,
  a LiveInstr's own when the graph allocator walks again. The walk's
  functions are INLINE, the recursive ones as wrappers around a local
  loop, so that each form gets its own copy with the accessor known.
  
  Measured with stage-1 compilers against the parent commit on x86-64:
  the assembly of perf/compiler's T3294, T12707, T783 and T9961 at -O0, -O
  and -O2 and of !16269's ManyBasicBlocks at -O0, -O1 and -O2
  is byte-identical, and so is that of T3294 and T9961 at -O
  under -fregs-graph and -fregs-iterative. The compiler allocates 0.89%
  less compiling T3294 at -O0, 0.86% less for T9961, 0.62% for T12707
  and 0.53% for T783, and 0.03 to 0.31% less at -O and -O2, but 0.04
  to 0.05% more for ManyBasicBlocks, which it compiles at -O1 in 0.34%
  fewer instructions under callgrind, its garbage collector copying less.
  
  Assisted-by: Claude Opus 5.5
  
  

• fec02739
  by Mikolaj Konarski at 2026-11-03T22:23:58+01:00

  Document behaviour of the NCG's CFG, layout and register allocators
  
  Comments and documentation only, on behaviour the earlier commits do
  not change; the generated code is the same.
  
  Dead code elimination is off under -finfo-table-map (GHC #20428),
  so the liveness pass gets no CFG and none is kept after register
  allocation: there is no static prediction for the layout and no chain
  layout under -fblock-layout-cfg. In GHC.CmmToAsm.Reg.Graph.SpillCost,
  a comment says that the block frequencies scale only the counts of uses
  and definitions, on which no spill choice depends.
  
  In GHC.CmmToAsm.CFG, Note [CFG Edge Weights] gave the default weight
  as 20k, where defaultWeights has 1000, and said that the false side
  of a regular branch is preferred, where both sides get the same weight
  and optHsPatterns' favourFewerPreds may prefer one by its predecessors,
  and that calls are ignored completely, where the layout leaves a call's
  edge out only while it builds chains and divides its weight by 64 when
  it merges them; it now also says that under -fcmm-static-pred
  the weights become estimated frequencies, for the layout and, estimated
  before allocation, for the linear allocator. Note [Layout relevant edge
  weights] in GHC.CmmToAsm.BlockLayout also said that calls are ignored,
  and now says how the layout treats them. Comments now say that edges
  of equal weight fall back on label order, which means nothing,
  and that where shortcutting redirects an edge onto one already there,
  one of them keeps its EdgeInfo and their weights are not summed;
  in GHC.CmmToAsm.BlockLayout, that allEdges' relevantWeight differs
  from directEdges'. Note [CFG based code layout] now says
  that the layout's loop analysis and mkGlobalWeights run for the layout
  only under -fcmm-static-pred, and the users' guide
  that -fcmm-static-pred works only on x86-64, for the linear allocator's
  order and, after register allocation and without -finfo-table-map,
  for the layout. In X86's genCondBranch', a comment says that the 3 added
  to the weight of a floating-point comparison's false edge breaks layout
  ties toward the side GHC.Cmm.ContFlowOpt makes likely.
  
  In the linear allocator, Note [Unique order in the linear allocator]
  says which decisions take the order of the vregs' uniques as a ranking,
  the spill victim and the order in which saveClobberedTemps moves values
  out of clobbered registers, and that it orders joinToTargets' fixup
  moves. The comments that said deterministic code generation
  was not supported, which -fobject-determinism provides, now say, there
  and in the liveness pass and the graph allocator, whether the order
  matters, and in GHC.Cmm.Node, GHC.Cmm.Reg and GHC.Platform.Reg
  that it is deterministic only where the uniques are. JoinToTargets'
  comment on cycles through memory now says that a vreg's slot changes
  where its format grows. In GHC.CmmToAsm.Reg.Liveness, the comment
  on the SCCs' order says that no block may fall through before
  allocation, and liveDieRead's haddock that at a branch it also holds
  the registers live into its targets only.
  
  Comments that were wrong before the series are corrected too. Step (j)
  of the linear allocator's outline, re-adding a dead spilled register's
  stack slot to the free list, is marked as not done, a StackMap never
  freeing a slot. calcBody's TODO, that its sort would be redundant
  were setElems ascending, is gone: the sort orders vertex numbers, which
  follow the reverse postorder. On AArch64, getFreeRegs scans the integer
  registers from x18 down, not from 28. FreeRegs' executable specification
  gives noFreeRegs as [] and getFreeRegs each instance's fixed order,
  where it handed out the registers most recently released first. X86's
  stmtToInstrs no longer assumes the condition likely false:
  GHC.Cmm.ContFlowOpt also inverts a condition whatever its likelihood
  where the false target has more than one predecessor.
  GHC.CmmToAsm.Reg.Linear.State cites Note [The one-shot state monad
  trick] on one line, where the notes linter matches it. linearRegAlloc's
  haddock and the comment over process say that a block is allocated
  before a jump into it if it is any of the procedure's entry blocks,
  not only its first, and that process drops a block whose assignment
  never gets set, where the comment said that it would loop. Note [CFG
  Edge Weights] gives likely and unlikely branches the 75% and 25%
  the default weights give them, where it said more than 80% and less
  than 20%.
  
  Assisted-by: Claude Opus 5.5
  
  

169 changed files:

• .gitmodules
• + changelog.d/T27323
• changelog.d/T27722-cbe-entry-block.md
• + changelog.d/T27847
• + changelog.d/T27979
• + changelog.d/T27994
• + changelog.d/caf-deadlock-27272
• + changelog.d/clc-446
• + changelog.d/clc-447
• + changelog.d/fix-nonmoving-weak-evacuation-race-23160
• + changelog.d/ghc-api-interactive-ids
• compiler/GHC/Cmm/CallConv.hs
• compiler/GHC/Cmm/CommonBlockElim.hs
• compiler/GHC/Cmm/Info/Build.hs
• compiler/GHC/Cmm/LayoutStack.hs
• compiler/GHC/Cmm/Node.hs
• compiler/GHC/Cmm/Opt.hs
• compiler/GHC/Cmm/Pipeline.hs
• compiler/GHC/Cmm/Reg.hs
• compiler/GHC/Cmm/Sink.hs
• compiler/GHC/CmmToAsm.hs
• compiler/GHC/CmmToAsm/AArch64.hs
• compiler/GHC/CmmToAsm/BlockLayout.hs
• compiler/GHC/CmmToAsm/CFG.hs
• compiler/GHC/CmmToAsm/Config.hs
• compiler/GHC/CmmToAsm/Instr.hs
• compiler/GHC/CmmToAsm/LA64.hs
• compiler/GHC/CmmToAsm/Monad.hs
• compiler/GHC/CmmToAsm/PPC.hs
• compiler/GHC/CmmToAsm/RV64.hs
• compiler/GHC/CmmToAsm/Reg/Graph.hs
• compiler/GHC/CmmToAsm/Reg/Graph/Spill.hs
• compiler/GHC/CmmToAsm/Reg/Graph/SpillCost.hs
• compiler/GHC/CmmToAsm/Reg/Linear.hs
• compiler/GHC/CmmToAsm/Reg/Linear/AArch64.hs
• compiler/GHC/CmmToAsm/Reg/Linear/Base.hs
• compiler/GHC/CmmToAsm/Reg/Linear/FreeRegs.hs
• compiler/GHC/CmmToAsm/Reg/Linear/JoinToTargets.hs
• compiler/GHC/CmmToAsm/Reg/Linear/State.hs
• compiler/GHC/CmmToAsm/Reg/Linear/X86_64.hs
• compiler/GHC/CmmToAsm/Reg/Liveness.hs
• compiler/GHC/CmmToAsm/Reg/Regs.hs
• compiler/GHC/CmmToAsm/X86.hs
• compiler/GHC/CmmToAsm/X86/CodeGen.hs
• compiler/GHC/CmmToAsm/X86/Instr.hs
• compiler/GHC/CmmToLlvm/CodeGen.hs
• compiler/GHC/CmmToLlvm/Config.hs
• compiler/GHC/Core/Coercion/Axiom.hs
• compiler/GHC/Core/Predicate.hs
• compiler/GHC/Core/TyCo/FVs.hs
• compiler/GHC/Core/TyCo/Subst.hs
• compiler/GHC/Core/Type.hs
• compiler/GHC/Core/Unify.hs
• compiler/GHC/Data/Graph/Directed.hs
• compiler/GHC/Driver/Config/CmmToAsm.hs
• compiler/GHC/Driver/Config/CmmToLlvm.hs
• compiler/GHC/Driver/Config/StgToCmm.hs
• compiler/GHC/Driver/DynFlags.hs
• compiler/GHC/Driver/Pipeline/Execute.hs
• compiler/GHC/Driver/Session.hs
• compiler/GHC/Hs/Decls.hs
• compiler/GHC/Hs/Dump.hs
• compiler/GHC/HsToCore/Match.hs
• compiler/GHC/HsToCore/Match/Literal.hs
• compiler/GHC/HsToCore/Monad.hs
• compiler/GHC/HsToCore/Pmc.hs
• compiler/GHC/HsToCore/Pmc/Desugar.hs
• compiler/GHC/HsToCore/Types.hs
• compiler/GHC/HsToCore/Utils.hs
• compiler/GHC/Parser.y
• compiler/GHC/Parser/PostProcess.hs
• compiler/GHC/Platform.hs
• + compiler/GHC/Platform/CpuFeatures.hs
• compiler/GHC/Platform/Reg.hs
• compiler/GHC/Runtime/Context.hs
• compiler/GHC/Runtime/Debugger.hs
• compiler/GHC/Runtime/Eval.hs
• compiler/GHC/Runtime/Eval/Types.hs
• compiler/GHC/Runtime/Heap/Inspect.hs
• compiler/GHC/StgToCmm/Config.hs
• compiler/GHC/StgToCmm/Prim.hs
• compiler/GHC/SysTools/Cpp.hs
• compiler/GHC/Tc/Instance/Family.hs
• compiler/GHC/Tc/Solver/FunDeps.hs
• compiler/GHC/Tc/Utils/Unify.hs
• compiler/GHC/Types/RepType.hs
• compiler/GHC/Types/Var/Env.hs
• compiler/ghc.cabal.in
• docs/users_guide/using-optimisation.rst
• ghc/GHCi/UI.hs
• ghc/GHCi/UI/Monad.hs
• libraries/base/changelog.md
• libraries/ghc-internal/src/GHC/Internal/Control/Exception/Base.hs
• libraries/ghc-internal/src/GHC/Internal/IO/Handle/Internals.hs
• libraries/ghc-internal/src/GHC/Internal/IO/Handle/Text.hs
• libraries/ghc-internal/src/GHC/Internal/IO/Handle/Windows.hs
• libraries/ghc-internal/src/GHC/Internal/System/Environment/ExecutablePath.hsc
• libraries/ghc-internal/src/GHC/Internal/System/IO/Error.hs
• rts/StgStdThunks.cmm
• rts/Weak.c
• rts/sm/Evac.c
• + testsuite/tests/cmm/should_compile/T27800.cmm
• + testsuite/tests/cmm/should_compile/T8327.cmm
• testsuite/tests/cmm/should_compile/all.T
• + testsuite/tests/cmm/should_compile/cmm_fold_elemAt.hs
• + testsuite/tests/cmm/should_compile/cmm_fold_lit.cmm
• + testsuite/tests/cmm/should_run/T27722.hs
• + testsuite/tests/cmm/should_run/T27722_cmm.cmm
• testsuite/tests/cmm/should_run/all.T
• + testsuite/tests/codeGen/should_compile/StackLayoutCallLoop.hs
• + testsuite/tests/codeGen/should_compile/StackLayoutTagLoop.hs
• + testsuite/tests/codeGen/should_compile/T27979.hs
• + testsuite/tests/codeGen/should_compile/T27979.stderr
• testsuite/tests/codeGen/should_compile/all.T
• testsuite/tests/codeGen/should_gen_asm/T24813.asm
• testsuite/tests/codeGen/should_gen_asm/bytearray-memcpy-unroll.asm
• testsuite/tests/codeGen/should_gen_asm/bytearray-memset-unroll.asm
• testsuite/tests/count-deps/CountDepsParser.stdout
• + testsuite/tests/exceptions/T27851.hs
• + testsuite/tests/exceptions/T27851.stderr
• + testsuite/tests/exceptions/T27851b.hs
• + testsuite/tests/exceptions/T27851b.stderr
• + testsuite/tests/exceptions/T27851c.hs
• + testsuite/tests/exceptions/T27851c.stdout
• + testsuite/tests/exceptions/T27851d.hs
• + testsuite/tests/exceptions/T27851d.stdout
• + testsuite/tests/exceptions/T27851d.stdout-javascript-unknown-ghcjs
• testsuite/tests/exceptions/all.T
• testsuite/tests/ghc-api/exactprint/Test20239.stderr
• testsuite/tests/ghc-e/should_fail/T18441fail7.stderr
• testsuite/tests/ghc-e/should_run/ghc-e005.stderr
• + testsuite/tests/ghci.debugger/scripts/RttiSharedTyVar.hs
• + testsuite/tests/ghci.debugger/scripts/RttiSharedTyVar.script
• + testsuite/tests/ghci.debugger/scripts/RttiSharedTyVar.stdout
• testsuite/tests/ghci.debugger/scripts/all.T
• + testsuite/tests/haddock/haddock_testsuite/IncrementalUnitId.hs
• testsuite/tests/haddock/haddock_testsuite/Makefile
• testsuite/tests/haddock/haddock_testsuite/all.T
• + testsuite/tests/haddock/haddock_testsuite/haddockIncrementalUnitId.stdout
• testsuite/tests/haddock/should_compile_flag_haddock/T17544.stderr
• testsuite/tests/haddock/should_compile_flag_haddock/T17544_kw.stderr
• testsuite/tests/haddock/should_compile_flag_haddock/T24221.stderr
• testsuite/tests/parser/should_compile/DumpParsedAst.stderr
• testsuite/tests/parser/should_compile/DumpRenamedAst.stderr
• testsuite/tests/parser/should_compile/T14189.stderr
• testsuite/tests/parser/should_compile/T15323.stderr
• testsuite/tests/parser/should_compile/T20452.stderr
• + testsuite/tests/pmcheck/should_compile/T27323.hs
• + testsuite/tests/pmcheck/should_compile/T27323b.hs
• testsuite/tests/pmcheck/should_compile/all.T
• testsuite/tests/printer/T18791.stderr
• + testsuite/tests/regalloc/T27619.hs
• testsuite/tests/regalloc/all.T
• + testsuite/tests/rts/T23160.hs
• + testsuite/tests/rts/T23160.stdout
• + testsuite/tests/rts/T27272.hs
• + testsuite/tests/rts/T27272_gen.py
• testsuite/tests/rts/all.T
• + testsuite/tests/typecheck/should_compile/T27994.hs
• + testsuite/tests/typecheck/should_compile/T27994a.hs
• + testsuite/tests/typecheck/should_compile/T27994b.hs
• testsuite/tests/typecheck/should_compile/all.T
• testsuite/tests/warnings/should_compile/Overflow.stderr-ws-32
• testsuite/tests/warnings/should_compile/Overflow.stderr-ws-64
• testsuite/tests/warnings/should_compile/T13256.stderr-ws-32
• testsuite/tests/warnings/should_compile/T13256.stderr-ws-64
• utils/check-exact/ExactPrint.hs
• utils/haddock/CHANGES.md
• utils/haddock/haddock-api/src/Haddock/Interface.hs

The diff was not included because it is too large.