intel/fs: Completely re-write the combine constants pass
authorIan Romanick <ian.d.romanick@intel.com>
Mon, 8 Jun 2020 22:18:19 +0000 (15:18 -0700)
committerMarge Bot <emma+marge@anholt.net>
Tue, 29 Aug 2023 19:01:36 +0000 (19:01 +0000)
commit44d62a5224d0a288ce38b94de678c599ee8b891e
tree5877331a62090b0fb3cbb0bfb094d2b729159e09
parente6625fa25a46095baa75b35caa9b3dab00f9b1b8
intel/fs: Completely re-write the combine constants pass

The is a squash of what in the original MR was "util: Add generic pass
that tries to combine constants" and "intel/fs: Switch to using
util_combine_constants".

The new algorithm uses a multi-pass greedy algorithm that attempts to
collect constants for loading in order of increasing degrees of freedom.
The first pass collects constants that must be emitted as-is (e.g.,
without source modifiers).

The second pass emits all constants that must be emitted (because they
are used in a source field that cannot be a literal constant) but that
can have a source modifier.

The final pass possibly emits constants that may not have to be emitted.
This is used for instructions where one of the fields is allowed to be a
constant.  This is not used in the current commit, but future commits
that enable SEL will use this.  The SEL instruction can have a single
constant, but when both sources are constant, one of the sources has to
be loaded into a register.

By loading constants in this order, required "choices" made in earlier
passes may be re-used in later passes.  This provides a more optimal
result.

At this point in the series, most platforms have the same results with
the new implementation.  Gen7 platforms see a significant number of
"small" changes.  Due to the coissue optimization on Gen7, each shader
is likely to have most constants affected by constant combining.

If a shader has only a single basic block, constants are packed into
registers in the order produced by the constant combining process.
Since each constant has a different live range in the shader, even
slightly different packing orders can have dramatic effects on the live
range of a register.  Even in cases where this does not affect register
pressure in a meaningful way, it can cause the scheduler to make very
different choices about the ordering of instructions.

From my analysis (using the `if (debug) { ... }` block at the end of
fs_visitor::opt_combine_constants), the old implementation and the new
implementation pick the same set of constants, but the order produced
may be slightly different.  For the smaller number of values in non-Gfx7
shaders, the orders are similar enough to not matter.

No shader-db or fossil-db changes on any non-Gfx7 platforms.

Haswell and Ivy Bridge had similar results. (Haswell shown)
total cycles in shared programs: 879930036 -> 880001666 (<.01%)
cycles in affected programs: 22485040 -> 22556670 (0.32%)
helped: 1879
HURT: 2309
helped stats (abs) min: 1 max: 6296 x̄: 258.54 x̃: 34
helped stats (rel) min: <.01% max: 54.63% x̄: 3.88% x̃: 0.87%
HURT stats (abs)   min: 1 max: 9739 x̄: 241.41 x̃: 40
HURT stats (rel)   min: <.01% max: 160.50% x̄: 6.01% x̃: 0.99%
95% mean confidence interval for cycles value: -1.04 35.25
95% mean confidence interval for cycles %-change: 1.23% 1.92%
Inconclusive result (value mean confidence interval includes 0).

LOST:   82
GAINED: 39

Tested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7698>
src/intel/compiler/brw_fs_combine_constants.cpp