<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Compiling of shader gets stuck in infinite loop"
href="https://bugs.freedesktop.org/show_bug.cgi?id=78468#c16">Comment # 16</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Compiling of shader gets stuck in infinite loop"
href="https://bugs.freedesktop.org/show_bug.cgi?id=78468">bug 78468</a>
from <span class="vcard"><a class="email" href="mailto:mike@LunarG.com" title="Mike Stroyan <mike@LunarG.com>"> <span class="fn">Mike Stroyan</span></a>
</span></b>
<pre>This extremely slow compilation is not actually an infinite loop.
But the compile time does increase with every unrolled loop step in the shader.
The time to complete is 2^N, where N is the number of loop iterations.
The call to
(*rvalue)->accept(this);
in ir_constant_folding_visitor::handle_rvalue is key to this.
Dropping that call for the case when rvalue is not a constant makes compilation
finish very quickly. And for at least this shader it produces exactly the
same results. Constant folding is done very effectively for the y and z
channels.
But the x channel still produces a series of adds of constants instead of one
add with the sum. That same pattern made the compilation faster for operations
on a full vec4 than for separate channels by limiting the complexity of the
expressions. But it is less efficient than the instructions created for the y
and z channels.
That is a separate issue that could still be investigated.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>