Stream: git-wasmtime

Topic: wasmtime / issue #4131 Cranelift: develop an alias analysis


view this post on Zulip Wasmtime GitHub notifications bot (May 10 2022 at 23:35):

cfallin labeled issue #4131:

We should build a simple alias analysis over CLIF to determine when loads and stores are referring to overlapping (may-alias) or the same (must-alias) data, and allow optimizations as appropriate (redundant-load elimination, store-to-load forwarding, dead-store elimination, code motion in general in LICM or lowering).

It is likely we will want to build a bitset-style analysis, where we have a small, finite set of disjoint divisions of the heap, and every load or store is marked as potentially accessing one or more.

For example, one could imagine a set of four bits for a Wasm frontend: accesses to any heap, accesses to any table, accesses to any global, or everything else (and explicitly not one of the above).

Given these bits for every load/store, we then have a "vector color" of sorts, in the sense that the current instruction coloring scheme could be seen to have a color per disjoint segment of world-state. We don't actually necessarily want to compute these vectors of colors, but we want to be able to answer questions using them.

view this post on Zulip Wasmtime GitHub notifications bot (May 10 2022 at 23:35):

cfallin opened issue #4131:

We should build a simple alias analysis over CLIF to determine when loads and stores are referring to overlapping (may-alias) or the same (must-alias) data, and allow optimizations as appropriate (redundant-load elimination, store-to-load forwarding, dead-store elimination, code motion in general in LICM or lowering).

It is likely we will want to build a bitset-style analysis, where we have a small, finite set of disjoint divisions of the heap, and every load or store is marked as potentially accessing one or more.

For example, one could imagine a set of four bits for a Wasm frontend: accesses to any heap, accesses to any table, accesses to any global, or everything else (and explicitly not one of the above).

Given these bits for every load/store, we then have a "vector color" of sorts, in the sense that the current instruction coloring scheme could be seen to have a color per disjoint segment of world-state. We don't actually necessarily want to compute these vectors of colors, but we want to be able to answer questions using them.

view this post on Zulip Wasmtime GitHub notifications bot (May 10 2022 at 23:35):

cfallin labeled issue #4131:

We should build a simple alias analysis over CLIF to determine when loads and stores are referring to overlapping (may-alias) or the same (must-alias) data, and allow optimizations as appropriate (redundant-load elimination, store-to-load forwarding, dead-store elimination, code motion in general in LICM or lowering).

It is likely we will want to build a bitset-style analysis, where we have a small, finite set of disjoint divisions of the heap, and every load or store is marked as potentially accessing one or more.

For example, one could imagine a set of four bits for a Wasm frontend: accesses to any heap, accesses to any table, accesses to any global, or everything else (and explicitly not one of the above).

Given these bits for every load/store, we then have a "vector color" of sorts, in the sense that the current instruction coloring scheme could be seen to have a color per disjoint segment of world-state. We don't actually necessarily want to compute these vectors of colors, but we want to be able to answer questions using them.

view this post on Zulip Wasmtime GitHub notifications bot (May 20 2022 at 20:19):

cfallin closed issue #4131:

We should build a simple alias analysis over CLIF to determine when loads and stores are referring to overlapping (may-alias) or the same (must-alias) data, and allow optimizations as appropriate (redundant-load elimination, store-to-load forwarding, dead-store elimination, code motion in general in LICM or lowering).

It is likely we will want to build a bitset-style analysis, where we have a small, finite set of disjoint divisions of the heap, and every load or store is marked as potentially accessing one or more.

For example, one could imagine a set of four bits for a Wasm frontend: accesses to any heap, accesses to any table, accesses to any global, or everything else (and explicitly not one of the above).

Given these bits for every load/store, we then have a "vector color" of sorts, in the sense that the current instruction coloring scheme could be seen to have a color per disjoint segment of world-state. We don't actually necessarily want to compute these vectors of colors, but we want to be able to answer questions using them.


Last updated: Dec 23 2024 at 12:05 UTC