https://bugs.llvm.org/show_bug.cgi?id=48122
Bug ID: 48122
Summary: Incorrect x86 code generation with extended asm
constraints and register asm variables.
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: andrew.coop...@citrix.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
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 https://godbolt.org/z/qGcavf 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. https://godbolt.org/z/erz41f
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.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
