nir/from_ssa: Only chain movs when a src is also a dest
authorJason Ekstrand <jason@jlekstrand.net>
Wed, 1 Apr 2020 20:05:18 +0000 (15:05 -0500)
committerMarge Bot <eric+marge@anholt.net>
Thu, 2 Apr 2020 19:06:46 +0000 (19:06 +0000)
commitc71c1f44b055c680f073a2608a3bf560b55f8974
tree5caaf3faa3f302560bfae7b1f557540f382ccb28
parent73e574acb85c06386dd59f11401eea43a2895d5a
nir/from_ssa: Only chain movs when a src is also a dest

The algorithm we use for resolving parallel copy instructions plays this
little shell game with the values.  The reason for this is that it lets
us handle cases where, for instance we have a -> b and b -> a and we
need to use a temporary to do a swap.  One result of this algorithm is
that it tends to emit a lot of mov chains which are typcially really bad
for GPUs where a mov is far from free.  For instance, it's likely to
turn this:

    r16 = ssa_0; r17 = ssa_0; r18 = ssa_0; r15 = ssa_0

into this:

    r15 = mov ssa_0
    r18 = mov r15
    r17 = mov r18
    r16 = mov r17

which, if it's the only thing in a block (this is common for phis) is
impossible for a scheduler to fix because of the dependencies and you
end up with significant stalling.  If, on the other hand, we only do the
chaining in the actual case where we need to free up a so that it can be
used as a destination, we can emit this:

    r15 = mov ssa_0
    r18 = mov ssa_0
    r17 = mov ssa_0
    r16 = mov ssa_0

which is far nicer to the scheduler.  On Intel, our copy propagation
pass will undo the chain for us so this has no shader-db impact.
However, for less intelligent back-ends, it's probably a lot better.

Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4412>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4412>
src/compiler/nir/nir_from_ssa.c