[llvm-bugs] [Bug 49365] New: x86 code generator uses shld/shrd incorrectly

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=49365

            Bug ID: 49365
           Summary: x86 code generator uses shld/shrd incorrectly
           Product: clang
           Version: 8.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C
          Assignee: unassignedclangbugs at nondot.org
          Reporter: appro at cryptogams.org
                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

Created attachment 24576
  --> https://bugs.llvm.org/attachment.cgi?id=24576&action=edit
minimal reproducer code snippet

Hi,

Even though I've clicked on version 8.0 as problematic, the problem was
observed even with clang versions 9, 10, and 11... On a potentially related
note, when the attached snippet is compiled separately, it doesn't matter if I
ask for 32- or 64-bit code. While in real-life application, when the subroutine
is declared static and can be inlined, only the 32-bit build appears to be
affected by the bug. (Well, with exception for clang 11, which did manage to
compile even 32-bit application correctly.)

While the attached reproducer snippet compiles to 'shld' instruction, in the
course of distilling the problem I could observe a similar behaviour even with
'shrd'. Moreover, at some point I even observed the compiler generating correct
code if I removed the last '&(BITS-1)' operation. (Yes, thus subjecting it to
undefined behaviour.)

The underlying problem appears to be that it's assumed that 'shld'/'shrd' would
handle %cl==64 by performing an actual 64-bit shift. I'm not claiming that the
assumption is actually made, only that it appears that way judging from
generated machine code:-)

The rest of the details is in the commentary section of the attached snippet.

Cheers.

-- 
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/20210226/a0eccc82/attachment.html>