[all-commits] [llvm/llvm-project] 7b0b77: PHIElim: Trim PHI source subranges without a full ...

[Matt Arsenault via All-commits]

  Branch: refs/heads/users/arsenm/codegen/phi-elim-subrange-kill-compile-time
  Home:   https://github.com/llvm/llvm-project
  Commit: 7b0b774ac78d3704824021787f88c053ec982eda
      https://github.com/llvm/llvm-project/commit/7b0b774ac78d3704824021787f88c053ec982eda
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2026-10-02 (Fri, 02 Oct 2026)

  Changed paths:
    M llvm/lib/CodeGen/MachineBasicBlock.cpp
    M llvm/lib/CodeGen/PHIElimination.cpp
    A llvm/test/CodeGen/AMDGPU/phi-elim-subreg-lanes-multi-pred.mir
    M llvm/test/CodeGen/Hexagon/phi-elim-subreg-lanes.mir

  Log Message:
  -----------
  PHIElim: Trim PHI source subranges without a full shrinkToUses

This contains a repurposed version of #226209, plus a supplemental fix branch
which was never posted. #228073 was an alternative implementation which landed
first; this replaces the brute-force shrinkToUses with targeted live range
adjustments. Some crude stress test benchmarking suggests this is 2-4x faster
measuring the pass in isolation.

shrinkToUses rescans every use of each subrange which is much more than is
necessary. The only segments that need changing are only the ones ending at the
inserted phi source copies. Instead, track the per-lane copies as they are
inserted and trim each lane at its last read, clamped to the predecessor block,
and stop SplitCriticalEdge from extending subranges for lanes the PHI does not
read. This keeps the live ranges correct while avoiding the per-subrange
rescans. The shrinkToUses implementation's cost scales with the number of uses,
but this remains relatively flat. An example with 640 uses is 7.2x faster.

Because this edits segments surgically instead of recomputing them, it has to
get the bounds exactly right in cases shrinkToUses handles. The clamp to the
predecessor block is one such case. Trimming a lane at its inserted copy must
not delete liveness for a later predecessor that reads the same lane. This is a
failure mode specific to the targeted approach, since a full shrinkToUses
rebuilds each subrange from all of its uses and so cannot over-trim. This failure
is stressed by the new tests and were broken in earlier revisions of the patch.

Copies into one predecessor are also not always inserted in index order, e.g.
the AMDGPU createPHISourceCopy override inserting after SI_IF, or the copy for
a landing pad going before the call. The recorded kills are kept sorted by
index, which is an append in the common case, so the search for the latest
read of a lane can stop at the first match.

Co-authored-by: Claude Opus 5 <noreply at anthropic.com>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications