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. -Thomas _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
