[all-commits] [llvm/llvm-project] 705aa2: [JumpThreading] Materialize PHIs in duplicateCondB...

[lijinpei-amd via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 705aa2a864d1573a17e62cfbcffbafdab7745a6d
      https://github.com/llvm/llvm-project/commit/705aa2a864d1573a17e62cfbcffbafdab7745a6d
  Author: lijinpei-amd <jinpli at amd.com>
  Date:   2026-07-29 (Wed, 29 Jul 2026)

  Changed paths:
    M llvm/lib/Transforms/Scalar/JumpThreading.cpp
    A llvm/test/Transforms/JumpThreading/dup-cond-br-recursive-phi.ll
    M llvm/test/Transforms/JumpThreading/phi-copy-to-pred.ll

  Log Message:
  -----------
  [JumpThreading] Materialize PHIs in duplicateCondBranchOnPHIIntoPred (#204859)

In duplicateCondBranchOnPHIIntoPred, updateSSA iteratively updates the
uses of
the instructions of BB (the duplicated block) according to ValueMapping.
For
PHIs, however, the mapping is inconsistent: the keys refer to the values
before
the parallel assignment of the PHIs, while the mapped-to values refer to
the
values after it. E.g.

  BB:
    %arr  = phi [ %ov.0, %PredBB ], ...
    %ov.0 = phi [ %ov.sel, %PredBB ], ...
  --->
    %arr  => %ov.0
    %ov.0 => %ov.sel

So an iterative replacement miscompiles: a use of the duplicated %arr is
replaced by %ov.sel, while the correct replacement is %ov.0.

Fix this by splitting PredBB -> BB (SplitEdge) into a PredEdgeBB,
cloning the
PHIs into PredEdgeBB and mapping BB's PHIs to the clones:

  BB:
    %arr  = phi [ %ov.0, %PredEdgeBB ], ...
    %ov.0 = phi [ %ov.sel, %PredEdgeBB ], ...
  PredEdgeBB:
    %arr.dup  = phi [ %ov.0, %PredBB ]
    %ov.0.dup = phi [ %ov.sel, %PredBB ]
  --->
    %arr  => %arr.dup
    %ov.0 => %ov.0.dup

Since a distinct set of PHIs is used as the mapped-to values, the
iterative
replacement is correct.

Fixes #197725.
Fixes #203868.

Assisted-by: Opus-4.8 (Claude Code)



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