0824abbae4
This PR adds a basic *alias analysis*, and optimizations that use it. This is a "mid-end optimization": it operates on CLIF, the machine-independent IR, before lowering occurs. The alias analysis (or maybe more properly, a sort of memory-value analysis) determines when it can prove a particular memory location is equal to a given SSA value, and when it can, it replaces any loads of that location. This subsumes two common optimizations: * Redundant load elimination: when the same memory address is loaded two times, and it can be proven that no intervening operations will write to that memory, then the second load is *redundant* and its result must be the same as the first. We can use the first load's result and remove the second load. * Store-to-load forwarding: when a load can be proven to access exactly the memory written by a preceding store, we can replace the load's result with the store's data operand, and remove the load. Both of these optimizations rely on a "last store" analysis that is a sort of coloring mechanism, split across disjoint categories of abstract state. The basic idea is that every memory-accessing operation is put into one of N disjoint categories; it is disallowed for memory to ever be accessed by an op in one category and later accessed by an op in another category. (The frontend must ensure this.) Then, given this, we scan the code and determine, for each memory-accessing op, when a single prior instruction is a store to the same category. This "colors" the instruction: it is, in a sense, a static name for that version of memory. This analysis provides an important invariant: if two operations access memory with the same last-store, then *no other store can alias* in the time between that last store and these operations. This must-not-alias property, together with a check that the accessed address is *exactly the same* (same SSA value and offset), and other attributes of the access (type, extension mode) are the same, let us prove that the results are the same. Given last-store info, we scan the instructions and build a table from "memory location" key (last store, address, offset, type, extension) to known SSA value stored in that location. A store inserts a new mapping. A load may also insert a new mapping, if we didn't already have one. Then when a load occurs and an entry already exists for its "location", we can reuse the value. This will be either RLE or St-to-Ld depending on where the value came from. Note that this *does* work across basic blocks: the last-store analysis is a full iterative dataflow pass, and we are careful to check dominance of a previously-defined value before aliasing to it at a potentially redundant load. So we will do the right thing if we only have a "partially redundant" load (loaded already but only in one predecessor block), but we will also correctly reuse a value if there is a store or load above a loop and a redundant load of that value within the loop, as long as no potentially-aliasing stores happen within the loop.
45 lines
1.2 KiB
Plaintext
45 lines
1.2 KiB
Plaintext
test alias-analysis
|
|
set opt_level=speed
|
|
target aarch64
|
|
|
|
;; Test that extension modes are properly accounted for when deciding
|
|
;; whether loads alias.
|
|
|
|
function %f0(i64 vmctx, i32) -> i32, i32, i32, i64, i64, i64 {
|
|
gv0 = vmctx
|
|
gv1 = load.i64 notrap readonly aligned gv0+8
|
|
heap0 = static gv1, bound 0x1_0000_0000, offset_guard 0x8000_0000, index_type i32
|
|
|
|
block0(v0: i64, v1: i32):
|
|
v2 = heap_addr.i64 heap0, v1, 0
|
|
|
|
;; Initial load. This will not be reused by anything below, even
|
|
;; though it does access the same address.
|
|
v3 = load.i32 v2+8
|
|
|
|
;; These loads must remain (must not be removed as redundant).
|
|
v4 = uload8.i32 v2+8
|
|
; check: v4 = uload8.i32 v2+8
|
|
v5 = sload8.i32 v2+8
|
|
; check: v5 = sload8.i32 v2+8
|
|
v6 = load.i64 v2+8
|
|
; check: v6 = load.i64 v2+8
|
|
|
|
;; 8-bit store only partially overwrites the address.
|
|
istore8 v6, v2+8
|
|
|
|
;; This must not pick up the store data.
|
|
v7 = load.i64 v2+8
|
|
; check: v7 = load.i64 v2+8
|
|
|
|
;; Another store, this one non-truncating but actually using an
|
|
;; `i8` value.
|
|
v8 = iconst.i8 123
|
|
store.i8 v8, v2+8
|
|
|
|
v9 = load.i64 v2+8
|
|
; check: v9 = load.i64 v2+8
|
|
|
|
return v3, v4, v5, v6, v7, v9
|
|
}
|