Skip to content

LocalCSE: Migrate from invalidates to orderedBefore#8744

Open
tlively wants to merge 3 commits into
mainfrom
local-cse-ordered-effects
Open

LocalCSE: Migrate from invalidates to orderedBefore#8744
tlively wants to merge 3 commits into
mainfrom
local-cse-ordered-effects

Conversation

@tlively
Copy link
Copy Markdown
Member

@tlively tlively commented May 21, 2026

Replace the coarse invalidates check in LocalCSE with orderedBefore.
This allows LocalCSE to reuse expression values across release stores,
while still correctly blocking reuse across acquire loads.

Add a lit test to verify the asymmetrical reordering behavior with
release/acquire atomics on shared GC structs and Wasm memory.

tlively added 2 commits May 20, 2026 18:13
Replace the coarse `invalidates` check and the coarse global state check
in LICM with more precise `orderedBefore` checks. This allows LICM to
move memory accesses past release stores, while still correctly blocking
them from moving past acquire loads.

Add a lit test to verify the asymmetrical reordering behavior with
release/acquire atomics on shared memory/GC structs.
Replace the coarse `invalidates` check in `LocalCSE` with `orderedBefore`.
This allows `LocalCSE` to reuse expression values across release stores,
while still correctly blocking reuse across acquire loads.

Add a lit test to verify the asymmetrical reordering behavior with
release/acquire atomics on shared GC structs and Wasm memory.
@tlively tlively requested a review from a team as a code owner May 21, 2026 01:28
@tlively tlively requested review from stevenfontanella and removed request for a team May 21, 2026 01:28
Comment thread src/passes/LocalCSE.cpp
}
auto& originalInfo = kv.second;
if (effects.invalidates(originalInfo.effects)) {
if (effects.orderedBefore(originalInfo.effects)) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have [original, curr] as the order of expressions. Shouldn't we invalidate like this?

Suggested change
if (effects.orderedBefore(originalInfo.effects)) {
if (!effects.orderedAfter(originalInfo.effects)) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i.e. effects/curr begin after. Should we not ask if they must remain after, as before/after is not symmetric?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is correct-as is. Say we have A; B; A', where A and A' is the same, so CSE is trying to optimize out A' and use the result of A instead. This is semantically the same as reordering A' to be before B (or alternatively B after A'): A; A'; B, so we want to invalidate the optimization if B ordered-before A', preventing the move. You're right that originalInfo.effects is calculated from A, but A' is the same expression, so here we're using it as A''s effects. So checking B ordered-before A' is the same as effects.orderedBefore(originalInfo.effects).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks. Maybe add a comment? Specifically the bit about using the effects of original to model those of the thing being optimized away, which is later, seems non-obvious.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added a comment clarifying that originalInfo.effects is standing in for COPY's effects.

Copy link
Copy Markdown
Member

@kripken kripken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Base automatically changed from licm-ordered-effects to main May 21, 2026 23:18
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