[llvm-bugs] [Bug 42044] New: Incorrect result with inline asm and rev16

[via llvm-bugs]

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

            Bug ID: 42044
           Summary: Incorrect result with inline asm and rev16
           Product: clang
           Version: 3.8
          Hardware: Other
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: noloader at gmail.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

I'm working on a Tinkerboard running Raspbian. It is a Cortex A-17 machine. It
has Clang 3.8 installed.

The following is producing incorrect results. I came across the case when
removing an uint32_t casts because it produced an extra uxth. I'm not sure if
this is expected or something is sideways.

$ cat test.cxx
#include <stdint.h>

uint16_t ByteReverse(uint16_t value)
{
  uint16_t rvalue;
  __asm__ ("rev16 %0, %1" : "=r" (rvalue) : "r" (value));
  return rvalue;
}

int main(int argc, char* argv[])
{
  uint16_t u = argc;
  u = ByteReverse(u);

  return u;
}

$ clang++ -O1 test.cxx -o test.exe
$ ./test.exe v v v v v
$ echo $?
0

I'm not sure what is going on since the rev16 is present:

$ clang++ -O1 test.cxx -c
$ objdump -d test.o
...

00000000 <_Z11ByteReverset>:
   0:   e6bf0fb0        rev16   r0, r0
   4:   e6ff0070        uxth    r0, r0
   8:   e12fff1e        bx      lr

0000000c <main>:
   c:   e92d4800        push    {fp, lr}
  10:   e1a0b00d        mov     fp, sp
  14:   e6ff0070        uxth    r0, r0
  18:   ebfffffe        bl      0 <_Z11ByteReverset>
  1c:   e8bd8800        pop     {fp, pc}

According to the ARM manual, rev16 performs:

    if ConditionPassed() then
        EncodingSpecificOperations();
        bits(32) result;
        result<31:24> = R[m]<23:16>;
        result<23:16> = R[m]<31:24>;
        result<15:8>  = R[m]<7:0>;
        result<7:0>   = R[m]<15:8>;
        R[d] = result;

It does not appear a half word is jumping from lo to hi (or vice versa). The
result of interest should be located in either <15:0> or <31:16>, which is
where it was located before rev16.

-- 
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/20190528/1b625b26/attachment.html>