Wasmtime GitHub notifications bot (May 19 2022 at 23:22): Wasmtime GitHub notifications bot (May 19 2022 at 23:22):cfallin opened issue #4167:
In #4163, we have an alias analysis that right now we will use to eliminate redundant loads.
However, in principle we could also eliminate dead stores -- stores that are not observed and that are known to be overwritten by some other store, hence completely invisible.
This is quite a bit more complicated in a world where traps exist and precise state must be observed at the trap point (and where the store itself can trap); so we should carefully evaluate whether this is actually worth it, and whether much opportunity exists under these constraints. But it may still be worthwhile.
We will at least need to ensure that:
- The store can be proved not to trap (e.g., another access to the same memory category dominates this store, with the same or a greater address/offset);
- There is another store to the same address that postdominates this store (all paths from this store go through the postdominating aliasing store eventually);
- No loads observe, or even may observe, the store (no loads in the same memory category);
- No trapping instructions, calls, or fences/atomics between the store and the shadowing store.
Wasmtime GitHub notifications bot (May 19 2022 at 23:22):cfallin labeled issue #4167:
In #4163, we have an alias analysis that right now we will use to eliminate redundant loads.
However, in principle we could also eliminate dead stores -- stores that are not observed and that are known to be overwritten by some other store, hence completely invisible.
This is quite a bit more complicated in a world where traps exist and precise state must be observed at the trap point (and where the store itself can trap); so we should carefully evaluate whether this is actually worth it, and whether much opportunity exists under these constraints. But it may still be worthwhile.
We will at least need to ensure that:
- The store can be proved not to trap (e.g., another access to the same memory category dominates this store, with the same or a greater address/offset);
- There is another store to the same address that postdominates this store (all paths from this store go through the postdominating aliasing store eventually);
- No loads observe, or even may observe, the store (no loads in the same memory category);
- No trapping instructions, calls, or fences/atomics between the store and the shadowing store.
Wasmtime GitHub notifications bot (May 19 2022 at 23:22):cfallin labeled issue #4167:
In #4163, we have an alias analysis that right now we will use to eliminate redundant loads.
However, in principle we could also eliminate dead stores -- stores that are not observed and that are known to be overwritten by some other store, hence completely invisible.
This is quite a bit more complicated in a world where traps exist and precise state must be observed at the trap point (and where the store itself can trap); so we should carefully evaluate whether this is actually worth it, and whether much opportunity exists under these constraints. But it may still be worthwhile.
We will at least need to ensure that:
- The store can be proved not to trap (e.g., another access to the same memory category dominates this store, with the same or a greater address/offset);
- There is another store to the same address that postdominates this store (all paths from this store go through the postdominating aliasing store eventually);
- No loads observe, or even may observe, the store (no loads in the same memory category);
- No trapping instructions, calls, or fences/atomics between the store and the shadowing store.
Wasmtime GitHub notifications bot (May 19 2022 at 23:22):cfallin labeled issue #4167:
In #4163, we have an alias analysis that right now we will use to eliminate redundant loads.
However, in principle we could also eliminate dead stores -- stores that are not observed and that are known to be overwritten by some other store, hence completely invisible.
This is quite a bit more complicated in a world where traps exist and precise state must be observed at the trap point (and where the store itself can trap); so we should carefully evaluate whether this is actually worth it, and whether much opportunity exists under these constraints. But it may still be worthwhile.
We will at least need to ensure that:
- The store can be proved not to trap (e.g., another access to the same memory category dominates this store, with the same or a greater address/offset);
- There is another store to the same address that postdominates this store (all paths from this store go through the postdominating aliasing store eventually);
- No loads observe, or even may observe, the store (no loads in the same memory category);
- No trapping instructions, calls, or fences/atomics between the store and the shadowing store.
Wasmtime GitHub notifications bot (Apr 29 2026 at 20:17):fitzgen commented on issue #4167:
I mentioned this at a Cranelift meeting a week or so ago, but noting it down here for posterity in case I don't actually get around to implementing it as soon as I intend to:
I realized that we can do a particular subset of dead-store elimination with our existing alias analysis, and without needing to ensure that, e.g., there is another store that post-dominates the store we are removing. The subset is this: when the CLIF is storing the exact value that alias analysis has determined that memory location already has.
"Idempotent-store elimination"?
I think this can be useful for cleaning up component-model flags stuff in fused adapters after inlining, but need to investigate more. (cc https://github.com/bytecodealliance/wasmtime/issues/12311)
Last updated: May 03 2026 at 22:13 UTC