<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 - [X86] Poor codegen with STMXCSR/LDMXCSR combo."
href="https://bugs.llvm.org/show_bug.cgi?id=48033">48033</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[X86] Poor codegen with STMXCSR/LDMXCSR combo.
</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>All
</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>Backend: X86
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>andrea.dibiagio@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>craig.topper@gmail.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, pengfei.wang@intel.com, spatel+llvm@rotateright.com
</td>
</tr></table>
<p>
<div>
<pre>This is a spin-off of <a class="bz_bug_link
bz_status_NEW "
title="NEW - llvm-mca crashes with LDMXCSR and STMXCSR instructions in combination for some architectures."
href="show_bug.cgi?id=48024">bug 48024</a>.
```
void MXCSR_Crash()
{
const unsigned int PreviousMXCSR = _mm_getcsr();
_mm_setcsr(PreviousMXCSR & ~0x6000);
}
```
(<a href="https://gcc.godbolt.org/z/66cvvq">https://gcc.godbolt.org/z/66cvvq</a>)
Currently generates this:
stmxcsr -4(%rsp)
movl $-24577, %eax # imm = 0x9FFF
andl -4(%rsp), %eax
movl %eax, -8(%rsp)
ldmxcsr -8(%rsp)
retq
This codegen is sub-optimal. It is as if the compiler tried very hard to keep
alive the stack slot with the original value of MXCSR until the end of the
function.
This is suboptimal because it means that an extra stack slot (rsp - 8) has to
be used for the new value of MXCSR. If instead the original slot was reused,
the compiler could have emitted a MR variant of AND (read-modify-write), and it
would have avoided the use of an extra MOV.
GCC gets this right: the entire sequence is three instructions plus the RET.
stmxcsr -4(%rsp)
andl $-24577, -4(%rsp)
ldmxcsr -4(%rsp)
retq
I wonder if this poor codegen has to do with the fact that STMXCSR is defined
as having "unmodeled side-effects". Can it be that somehow that prevents the
compiler from commuting the original ADD and use a RMW variant instead?
Alternatively StackSlotColoring is not doing a good job at merging the two
stack slots. This is just me speculating on what the issue might be in the code
generator.
--
On the plus side, the compiler is smart at taking advantage of the red-zone in
this case. Part of me wasn't expecting to see negative offsets used with RSP.
In this particular case, it makes perfectly sense and it avoids having to emit
an extra SUB (of RSP) at the beginning, plus an extra ADD at the end.</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>