<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] Potential exec mask issue"
href="https://bugs.llvm.org/show_bug.cgi?id=37744">37744</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[AMDGPU] Potential exec mask issue
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</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>samuel.pitoiset@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=20411" name="attach_20411" title="small LLVM IR testcase">attachment 20411</a> <a href="attachment.cgi?id=20411&action=edit" title="small LLVM IR testcase">[details]</a></span>
small LLVM IR testcase
Hi,
The AMDGPU backend seems to be affected by an exec mask issue which ends up by
hanging a bunch of games with RADV and DXVK [1]. I do have a mesa workaround
[2] that I'm going to be push, but the right thing to do is to fix LLVM of
course. Though, that would be needed for LLVM < 7.
I attached a testcase called small-testcase.ll. Basically, the code does
something like:
if x == 0 && y == 0
result = 0
else
result = 0x3FAF48604
It first checks both x and y, then x and finally y (yeah, that's dumb but the
LLVM IR is correct). It does return the expected result when x == 0, but it
fails when x != 0.
If we look at the assembly after building with llc there is something
interesting.
In BB0_3, we check if x and y == 0, if it's true we jump to BB0_7, otherwise we
end up in BB0_4. In this block we check x, if x == 0 we execute the
instructions in BB0_5 (because EXEC != 0). When x != 0, these instructions are
implicitly "skipped", except s_or_b64 which sets s[10:11] to 0 because VCC is
0. But VCC was 1 in BB0_3, hmm.
Later on, in BB0_7 there is:
s_mov_b64 s[6:7], s[10:11]
But s[10:11] is set in two blocks (BB0_3 and BB0_5), looks weird. Well, it's a
PHI of SI_IF_BREAK and we have two breaks in that loop, maybe related?
One solution is to *explicitly* skip BB0_5 when EXEC == 0, that way we don't
override s[10:11]. I'm really not sure if that the best option but this is what
my workaround does, and it works.
Anyway, SIInsertSkips looks completely broken, we might want to insert the
skips in SILowerControlFlow and optimize later on.
I'm using latest LLVM trunk.
Any thoughts?
[1] <a href="https://github.com/doitsujin/dxvk/issues/252#issuecomment-395527247">https://github.com/doitsujin/dxvk/issues/252#issuecomment-395527247</a>
[2] <a href="https://bugs.freedesktop.org/attachment.cgi?id=140068">https://bugs.freedesktop.org/attachment.cgi?id=140068</a></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>