<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 - New assert: !(TSFlags & X86II::REX_W) && "REX.W requires 64bit mode.""
href="https://bugs.llvm.org/show_bug.cgi?id=36346">36346</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>New assert: !(TSFlags & X86II::REX_W) && "REX.W requires 64bit mode."
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</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>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>hans@chromium.org
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>We're seeing this in Chromium builds, see
<a href="https://bugs.chromium.org/p/chromium/issues/detail?id=811241">https://bugs.chromium.org/p/chromium/issues/detail?id=811241</a>
Bisection points to this commit:
---
Author: lsaba
Date: Sun Feb 11 01:34:12 2018
New Revision: 324835
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=324835&view=rev">http://llvm.org/viewvc/llvm-project?rev=324835&view=rev</a>
Log:
[X86] Reduce Store Forward Block issues in HW
If a load follows a store and reloads data that the store has written to
memory, Intel microarchitectures can in many cases forward the data directly
from the store to the load, This "store forwarding" saves cycles by enabling
the load to directly obtain the data instead of accessing the data from cache
or memory.
A "store forward block" occurs in cases that a store cannot be forwarded to the
load. The most typical case of store forward block on Intel Core
microarchiticutre that a small store cannot be forwarded to a large load.
The estimated penalty for a store forward block is ~13 cycles.
This pass tries to recognize and handle cases where "store forward block" is
created by the compiler when lowering memcpy calls to a sequence
of a load and a store.
The pass currently only handles cases where memcpy is lowered to XMM/YMM
registers, it tries to break the memcpy into smaller copies.
breaking the memcpy should be possible since there is no atomicity guarantee
for loads and stores to XMM/YMM.
----</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>