[llvm-bugs] [Bug 48122] New: Incorrect x86 code generation with extended asm constraints and register asm variables.

[via llvm-bugs]

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: unassignedclangbugs at nondot.org
          Reporter: andrew.cooper3 at citrix.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201109/48b20274/attachment.html>