Skip to content

compiler: Restore lifting cache in SROA perform_lifting!#61020

Open
aviatesk wants to merge 1 commit intomasterfrom
avi/lifting-cache
Open

compiler: Restore lifting cache in SROA perform_lifting!#61020
aviatesk wants to merge 1 commit intomasterfrom
avi/lifting-cache

Conversation

@aviatesk
Copy link
Member

When multiple getfield calls access the same field of the same phi node, the SROA pass creates duplicate lifted phi nodes. A lifting cache was originally intended to prevent this (#43927), but had been broken and later removed in PR #51014.

This restores a working lifting cache. The cache key includes both the field index and stmt_val (the original getfield argument) to distinguish liftings through the same phi node with different type constraints (e.g. direct access vs access through a PiNode that narrows the type). Without stmt_val in the key, a narrower type-constrained lifting could be incorrectly reused for a wider constraint, producing phi nodes with missing edges. Separate caches are used for getfield and isdefined liftings since they produce phi nodes with different value types.

When multiple `getfield` calls access the same field of the same phi
node, the SROA pass creates duplicate lifted phi nodes. A lifting cache
was originally intended to prevent this (#43927), but had been broken
and later removed in PR #51014.

This restores a working lifting cache. The cache key includes both the
field index and `stmt_val` (the original `getfield` argument) to
distinguish liftings through the same phi node with different type
constraints (e.g. direct access vs access through a PiNode that narrows
the type). Without `stmt_val` in the key, a narrower type-constrained
lifting could be incorrectly reused for a wider constraint, producing
phi nodes with missing edges. Separate caches are used for `getfield`
and `isdefined` liftings since they produce phi nodes with different
value types.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@aviatesk aviatesk requested a review from Keno February 13, 2026 13:35
@gbaraldi
Copy link
Member

Does this have any performance improvements?

@aviatesk
Copy link
Member Author

Since the number of generated PhiNodes will be reduced, there may be cases with an impact on LLVM compilation performance.
There will likely be almost no impact on Julia level compilation.

@oscardssmith
Copy link
Member

Would be nice to see some benchmarks to ensure this is positive/neutral.

@aviatesk
Copy link
Member Author

@nanosoldier runbenchmarks("inference", vs=":master")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants