fitzgen opened PR #14230 from fitzgen:alias-analysis-lattice to bytecodealliance:main:
There were two ways in which alias analysis's
LastStoresstate was not a proper lattice, which made the order we processed the worklist and calledLastStores::meetobservable:
We didn't have a single, canonical bottom value for the last store to a region. We were taking the first instruction in a block as an identifier for control-flow join points so that we would get different
MemoryLocs for different control-flow joins, which is necessary to avoid illegally forwarding a value loaded inside one control-flow join to a load in another, different control-flow join. However, this meant that we effectively had multiple bottom elements, which made the path we descended through the "lattice" observable. The solution here was to create a separateLastStoredataflow value that has a single, canonical bottom element, and a distinctMemoryVersionvalue that is the same asLastStorebut replaces its bottom value with a variant that identifies the associated control-flow join point. We useLastStorein ourLastStoreslattice, when we need a bottom element, and we useMemoryVersionin ourMemoryLockeys, to distinguish between different regions where we don't know anything about the contents of memory.We computed the observed-stores set while we computed the fixpoint of the initial
LastStoresinputs to each block. This was incorrect, however, because aLastStorescould transiently contain aLastStore::Instthat disappears in later iterations of the fixpoint, and which instructions do or don't transiently appear inLastStoresin that way depends on the order in which we callLastStores::meet. Therefore, observing stores while computing the fixpoint might or might not observe an instruction depending on the worklist processing order. The solution in this case was to only compute the observed-stores set after we've computed theLastStoresfixpoint, at which point there are no transientLastStore::Insts anymore.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.mdPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
fitzgen requested wasmtime-compiler-reviewers for a review on PR #14230.
fitzgen requested wasmtime-core-reviewers for a review on PR #14230.
fitzgen requested cfallin for a review on PR #14230.
github-actions[bot] added the label cranelift on PR #14230.
Last updated: Aug 30 2026 at 09:07 UTC