<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [AMDGPU] Hang with gallium nine lighting shader likely caused by bad compilation"
href="https://bugs.llvm.org/show_bug.cgi?id=36704">36704</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[AMDGPU] Hang with gallium nine lighting shader likely caused by bad compilation
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>5.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Backend: AMDGPU
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>davyaxel0@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=20054" name="attach_20054" title="tgsi, llvm and asm">attachment 20054</a> <a href="attachment.cgi?id=20054&action=edit" title="tgsi, llvm and asm">[details]</a></span>
tgsi, llvm and asm
This bug was previously entered here:
<a href="https://bugs.freedesktop.org/show_bug.cgi?id=105442">https://bugs.freedesktop.org/show_bug.cgi?id=105442</a>
But the more I think about it, the more it looks like it's an llvm bug, not a
mesa bug.
The shader (see attachment for TGSI, llvm and generated asm, buggy vs non-buggy
shader) is a shader with a loop that iterates over lights, and stops when a
specific constant relative to the light is set to 1 [32+7+8*num of the light].w
With git mesa and llvm 5.0.1, the shader hangs, but not with mesa 17.2. I first
thought it was related to mesa in particular, but it is more likely the
difference in the llvm asm triggers the buggy llvm behaviour.
When you compare the faulty shader, you'll see in the generated shader at the
beginning of the loop:
s_branch BB0_2 ; BF820000
v_add_f32_e32 v20, 0x41000000, v20 ; 022828FF 41000000
Whereas the non-buggy shader adds the 8 (because we iterate over the lights) at
the end of the loop.
According to the s_branch encoding, it should do PC = PC + 4
It is unclear to me where we end up with this jump, but my guess is either this
ends up on the v_add, and thus the branch is noop - and this is bad because we
miss the first light -, or maybe (the instruction is 8 bytes long) we end up in
the middle of the instruction at execute 41000000 as if it was an instruction
and not a constant.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>