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.
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.
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.
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.
Last updated: Nov 22 2024 at 17:03 UTC