[Mesa-dev] LICM vs GCM

Thomas Helland thomashelland90 at gmail.com
Sat Aug 15 07:43:34 PDT 2015

Hi all,

I'm now doing the last modifications to the loop analysis pass
I've been working on, and I stumbled upon something I found
a bit surprising. (Keep in mind I'm not very familiar with GCM)

Some background info: there are 550 loops in my shader-db.
The glsl unrolling unrolls 150 of those. My pass detects
the trip-count for aprox 100 of those when the unrolling
in glsl is deactivated. The times it fails is because I'm not able
to detect a valid induction variable (25 % of times) and because
the upper limit for the iteration is unknown (75 % of times).
Also, 25 % of loops does not have a nir_jump_break...

I was thinking I might be able to increase on those numbers
by doing some LICM to possibly simplify things. I didn't feel
like writing a LICM just to test that, and so I remembered
the "do we want LICM"-discussion on irc, where the conclusion
was that GCM should be handling that, and so there shouldn't
be a need. So I went ahead and activated it.

The result was an inflation in the amount of ssa-defs inside loops
by about 800. (From 12667 to 13463). It pulls in about 156
load_consts, which I guess is harmless, but it also increases the
amount of loop-invariant alu-ops inside loops from 184 to 514.
That doesn't seem like a good deal to me. Is this expected behavior?
I know the GCM-pass is not activated by default, and probably for a
reason, but I was a bit surprised by the results so thought I'd report it.


More information about the mesa-dev mailing list