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)
Wasmtime GitHub notifications bot (Jun 11 2026 at 22:02):fitzgen commented on issue #4167:
So Chris and I talked about this a little more yesterday. It is coming up again in the context of https://github.com/bytecodealliance/wasmtime/issues/12311 as well.
Computing post-dominators is probably not too bad. Flip the CFG edges, add a virtual sink node that all returns and unconditional traps flow from, then compute dominators using the same code we have today.
But what is more tricky is that I think dead-store elimination wants to be a backwards pass (from post-dominators to post-dominatees) which means it won't integrate well with the egraph pass's forwards traversal over the IR.
Additionally, removing a dead store can cascade into a load becoming dead, which can cascade into more loads/stores becoming dead, etc... See the sequence of dead store/load/stack-slot removal in this comment, for example.
But maybe this is okay? I think removing a dead store can only cause more code to become dead, I don't think it can expose more opportunities for store-to-load forwarding or redundant-load elimination than we already had? Because if it did, then we would want to run those optimizations again, but they are part of our forwards pass, so we would devolve into phase ordering issues and/or forwards-backwards fixpoints and such...
Wasmtime GitHub notifications bot (Jun 11 2026 at 22:02):fitzgen edited a comment on issue #4167:
So Chris and I talked about this a little more yesterday. It is coming up again in the context of https://github.com/bytecodealliance/wasmtime/issues/12311 as well.
Computing post-dominators is probably not too bad. Flip the CFG edges, add a virtual sink node that all returns and unconditional traps flow from, then compute dominators using the same code we have today.
But what is more tricky is that I think dead-store elimination wants to be a backwards pass (from post-dominators to post-dominatees) which means it won't integrate well with the egraph pass's forwards traversal over the IR.
Additionally, removing a dead store can cascade into a load becoming dead, which can cascade into more loads/stores becoming dead, etc... See the sequence of dead store/load/stack-slot removal in this comment, for example.
But maybe this is okay, and we could do it during lowering (which is backwards)? I think removing a dead store can only cause more code to become dead, I don't think it can expose more opportunities for store-to-load forwarding or redundant-load elimination than we already had? Because if it did, then we would want to run those optimizations again, but they are part of our forwards pass, so we would devolve into phase ordering issues and/or forwards-backwards fixpoints and such...
Wasmtime GitHub notifications bot (Jun 11 2026 at 22:06):cfallin commented on issue #4167:
Hmm, yeah, that's a good point.
I think it may be possible to do something that's kind of janky, but still enough for our goal (cleaning up adapters' flag updates), during the forward pass: when we see another store that post-doms a store, and the post-dom'd store has seen no reads (no loads that may have aliased -- so every load either was in a different region, or same region but provably different address, e.g.
v0+K1andv0+K2whereK1 != K2), we can "reach backward" and delete the first store.That may then leave the store's uses (address and value) dead, but lowering will already skip over dead values by its very nature. The only thing we don't get is the dead-store cascade through an arbitrary chain of loads/stores, as you say.
Wasmtime GitHub notifications bot (Jul 01 2026 at 15:56):fitzgen assigned fitzgen to issue #4167.
Wasmtime GitHub notifications bot (Jul 23 2026 at 00:26):fitzgen closed 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.
Last updated: Jul 29 2026 at 05:03 UTC