<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 - Incorrect x86 code generation with extended asm constraints and register asm variables."
href="https://bugs.llvm.org/show_bug.cgi?id=48122">48122</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Incorrect x86 code generation with extended asm constraints and register asm variables.
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</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>C
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>andrew.cooper3@citrix.com
</td>
</tr>
<tr>
<th>CC</th>
<td>blitzrakete@gmail.com, dgregor@apple.com, erik.pilkington@gmail.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>Hello,
This is arguably a "doesn't behave like GCC" issue, but it did regress between
Clang 8 and 9, and is still problematic on mainline.
I've simplified the repro to <a href="https://godbolt.org/z/qGcavf">https://godbolt.org/z/qGcavf</a> but it probably needs
some explanation.
This is a simplification of some kernel code using the Xen hypercall interface.
Under the Xen 64bit ABI, the 4th parameter is passed in %r10, and is clobbered
by the hypercall.
The problem is the hoisting of the DOMID_SELF constant setup outside of the
loop, because %r10 is clobbered on each loop iteration.
The issue appears to be the interaction of using `register unsigned long _a4
asm ("r10")` to set up the constraint and force it to be in %r10. The
association with %r10 is honoured for the input ("4") but not honoured for the
matched output ("=&r" (__ign4)), which is present to declare that the output
value is discarded.
I did experiment and rewrite the _hypercall64_4() macro to use the "+r" output
operand form. <a href="https://godbolt.org/z/erz41f">https://godbolt.org/z/erz41f</a>
This does cause %r10 to be reloaded with 0x7ff0 on each iteration of the loop,
and AFAICT is correct code.
I have actually used this to work around the bug, but it does make the code
harder to follow which is why I wrote it the former way first.</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>