This increases the size of RegRef to 32 bits but that's fine given that
it's usually in a union with SSARef which is 128 bits. The real
advantage is that it allows us to start treating memory as a register
type which will come in really useful for spilling.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
This gets rid of most of the per-block hash maps and replaces them all
with vectors. This is both simpler and should be quite a bit more
efficient (though block lookup isn't common).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
This renames CFG to CFG2 and moves to storing the blocks in a CFG
instead of a Vec. This should let us make a bunch of other data
structures drop to a vec instead of a hash map now that we can rely on
the CFG instead of BasicBlock::id.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
This is a pair of vectors but it acts a bit like a vector of a pair.
Everything is inserted, removed, iterated, etc. in tandem to ensure that
we never mismatch between the two vectors. However, because they're two
separate vectors, we ensure that it can be used to store Src and Dst and
keep everything contiguous.
Of particular interest is the new retain() method which is equivalent to
Vec::retain() which allows filtering a VecPair. This tricky operation
is performed three different times by DCE and will be needed in spilling
as well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
This one is much faster to compute because we can use bitops for the
fixed-point data-flow algorithm rather than the clumsy walking of hash
sets. The faster version is sufficient for RA and checking for register
pressure. We only need to fall back to the slower version for spilling.
Thanks to traits, we can get some of the same behavior with both.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
One could argue that this should go in the function and not be an
on-demand analysis pass but we can do that later. For now, we just
break it out into a separate data structure.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
Instead of tracking pinned things in the register allocator, we split
the register allocator into RegAllocator and PinnedRegAllocator. The
RegAllocator struct only allows for very simple single-SSA allocations
and frees. It tracks locations of everything, what's used, etc. but
otherwise knows nothing about pinning or vectors.
The new PinnedRegAllocator struct wraps a RegAllocator by taking a
mutable reference to it. It provides support for pinning and all the
vector stuff. To destroy a PinnedRegAllocator, finish() is called which
re-places any evicted SSA values and populates an OpParCopy with any
needed copies. Because PinnedRegAllocator owns a mutable reference to
the RegAllocator, it's impossible to mix uses of PinnedRegAllocator and
RegAllocator. This ensures that, for as long as the pinned version
exists, nothing can be allocated which migh escape the pinning.
This fixes a bunch of corner cases when register pressure gets tight.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
Since the top value is always the default register, we don't need to
worry about overflowing a u8. What we do need to worry about is
register files with zero registers which is a thing pre-Turing for
uniform register files. Use num instead of max so we don't end up
subtracting 1 from 0.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
While coping the entire RA struct from the predecessor is probably
faster, it may contain values which are not live in the current block.
We could purge those but the iteration gets tricky with Rust. It's far
clearer and more rust-friendly to deal with it as an initialization
problem.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
Sometimes it's useful to have something that's per-register-file like we
do for register allocation. Since this is generally useful, add a
struct for it. In future, it might be neat to pull in the enum_map
crate which basically does this generically.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
If we walk the blocks forwards, we end up having a minimum O(n^2)
algorithm because everything has to propagate bottom to top. Looping
over the blocks bacwards ensures that all the liveness information is
propgated in the first pass in the absence of back edges.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24998>
