AOT: enum match($this) compile outcome depends on helper-cache state — same commit both compiles and fails module verification

[PurHur]

Summary

m04_enum_match_this and k06_enum_backed_match compile successfully in some runs and fail LLVM
module verification in others — on the same commit, same image, same source:

PHP Fatal error: Uncaught RuntimeException: Module verification failed due to
                 PHI node entries do not match predecessors!

The determining factor appears to be the helper-runtime cache state, not the code.

Evidence

Two full differential sweeps, both cold-started, both on master around a279902fc:

sweep A:  ok      m04_enum_match_this.php   (3/3 runs)     ok      k06_...  (3/3 runs)
sweep B:  COMPILE m04_enum_match_this.php                  COMPILE k06_...

Single-shot compiles of m04 right now return the PHI error at every commit I tested:

a279902fc  phi_error=1      dac8065a0  phi_error=1
64d006e75  phi_error=1      c5b12a6b4  phi_error=1
33b43eea8  phi_error=1      e051bd155  phi_error=1
84565e364  phi_error=1      master     phi_error=1

Including a279902fc — the commit where sweep A reported ok 3/3. So this is not commit-linked,
and bisecting it is a dead end.

What differs between the runs

Sweep A ran script/aot-smoke.sh first, which warms build/helper-runtime-cache with units emitted
during that run. Sweep B (and my single-shot checks) ran against a cache in a different state.

I tried to pin it to committed-prelinked-vs-freshly-emitted units and that hypothesis was
refuted — with PHP_COMPILER_HELPER_RUNTIME_CACHE_DIR pointed at a fresh temp dir, both paths
fail:

A: committed prelinked units        phi_errors=1, no binary
B: after emit-helper-runtime-object.php  phi_errors=1, no binary

So the cache state matters, but "which tier of units" is not the whole story, and I would rather say
that than guess further.

Why this is worth its own issue

1. A compile outcome that depends on cache state is a correctness problem, independent of the
   enum bug underneath it. The same source must compile the same way.
2. It makes the sweep an unreliable gate for these cases — they can land in the failing set or
   not depending on cache history, which is exactly the class of noise that produces phantom
   regressions. I hit this: two of my baselines disagreed on these two cases and I initially read it
   as a same-day regression.
3. #24163 is closed with these cases red. They currently fail on master.

Suggested next step

Dump the IR for the failing function under both cache states and diff it — the PHI node with
mismatched predecessors should be identifiable, and whether its predecessor set differs by cache
tier would say whether this is a lowering bug exposed by unit selection or a unit-linking bug.

Environment: php-compiler:22.04-dev, PHP 8.2.32, LLVM 9, master 235e9d7f2. Cases:
test/differential/cases/m04_enum_match_this.php, k06_enum_backed_match.php.

[PurHur]

claim: lane-B implementer — starting this run

Pillar 1 pre-check (this host):

• release-readiness --json: user_release_ready: yes (inventory 6614/6614, north-star5-fast ok, vm-driver-probe ok)
• gen-0 provenance: stale (informational; not blocking this AOT/PHI issue)

Scope: AOT m04_enum_match_this / k06_enum_backed_match PHI module-verify failure; reproduce + fix lowering/linking so compile outcome is cache-independent.

[PurHur]

Merged #24393

Fix: formatStringPtr PHI after JitStringConcat now uses the post-concat insert block (not umatch_fmt_nonempty).

Verified:

• Cold PHP_COMPILER_HELPER_RUNTIME_CACHE_DIR + HELPER_RUNTIME_O=0: m04/k06 compile+run → H black (3×)
• vendor/bin/phpunit --filter MatchEnumThisAotTest → OK (3 tests)

[PurHur]

Not reproducible now — and the likely factor was my own local cache state

All four enum cases are green on master 2f5973133, --repeat 3:

ok  k06_enum_backed_match    (3/3)      ok  m03_enum_from      (3/3)
ok  m01_enum_case_const      (3/3)      ok  m04_enum_match_this (3/3)

And m04 compiles cleanly in every configuration I tried today:

configuration	result
fresh cache dir, compile directly	rc=0, no PHI error
fresh cache dir, aot-smoke first, then compile	rc=0, prints H black
default build/helper-runtime-cache	rc=0, prints H black

What I think happened, stated as a hypothesis

When I ran the eight-commit check that returned phi_error=1 everywhere, my
build/helper-runtime-cache held units accumulated from a long series of runs that day — including a
--prelink refresh I later reverted, and several partial/aborted builds. That directory now holds
0 units, and the failure is gone.

So the most likely explanation is that specific stale units in my working tree's cache produced an
invalid module, not that master is state-dependent in general. I cannot prove that, because I cleared
the cache before realising it was the variable — the state that would demonstrate it no longer
exists.

What still stands, and what I withdraw

Stands: two full sweeps on the same master genuinely disagreed about k06/m04 (ok 3/3 vs
COMPILE). That is recorded in the run logs and is not something I inferred.

Withdraw: the framing that this is a general, ongoing state-dependence in the compiler. I do not
have evidence for that beyond one unreproducible episode, and leaving that claim standing would
misdirect whoever picks this up.

Still worth noting: a stale helper unit producing an LLVM module that fails verification is a
real failure mode regardless of how it got there. Unit freshness is keyed per-unit (#23458), so a
unit that survives an invalidation it should not is the shape to look for if this recurs.

If it recurs

Preserve the cache directory before doing anything else — cp -a build/helper-runtime-cache /tmp/bad-cache — then compare a compile against that cache with one against a fresh dir. Without the
polluted state there is nothing to diff, which is exactly why I could not finish this today.

Leaving open at low priority rather than closing: the sweep disagreement was real, and if it happens
again the recipe above should pin it in one run.