<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 - XMM constant wrongly hoisted past uses of corresponding YMM register"
href="https://bugs.llvm.org/show_bug.cgi?id=44140">44140</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>XMM constant wrongly hoisted past uses of corresponding YMM register
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>9.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</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: X86
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>edy.burt@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>craig.topper@gmail.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, spatel+llvm@rotateright.com
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=22866" name="attach_22866" title="Reduced testcase LLVM IR">attachment 22866</a> <a href="attachment.cgi?id=22866&action=edit" title="Reduced testcase LLVM IR">[details]</a></span>
Reduced testcase LLVM IR
See attached LLVM IR for a reduced testcase, which, when compiled (via llc + C
compiler), and executed:
* as-is: exits with -1 (indicating corruption of %data)
* after removing win64cc (from @opaque's definition and call): exits
successfully (indicating %data has the correct value)
My understanding of the reduced testcase is that:
1. X86 codegen takes advantage of xmm6 being callee-saved (for win64cc) to
hoist the <i64 1010101010101010101, i64 2020202020202020202> constant across
the @opaque call and out of the (fake) loop, keeping it around in xmm6
2. the two copies (%dummy1 -> %dummy2 and %dummy2 -> %dummy3) result in enough
AVX registers being used (ymm0-ymm6) to overlap with xmm6, effectively
corrupting the latter
3. by the time of the actual store to %data, whatever happened to be in ymm6's
lower half gets stored, instead of the hoisted constant
Note: this bug was observed initially on win64 target-cpu=znver1 hosts, but it
doesn't seem to require a win64 host (just the calling convention), nor an AMD
Ryzen host (just the znver1 codegen, presumably for its cost tables, and an
AVX-capable CPU).</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>