[llvm-bugs] [Bug 43073] New: Opus miscompiled for ARM after ParallelDSP change r367389

[via llvm-bugs]

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

            Bug ID: 43073
           Summary: Opus miscompiled for ARM after ParallelDSP change
                    r367389
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: hans at chromium.org
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    sam.parker at arm.com

Some WebRTC tests which use Opus started failing on Android after LLVM r367389
(https://bugs.chromium.org/p/webrtc/issues/detail?id=10887)

It's very possible that the change itself is fine, but that it exposed
ParallelDSP to more code that then got miscompiled due to some already existing
bug in the pass.


Here's a reduced repro which I think shows the problem:


b.c:

typedef short int16_t;
typedef unsigned short uint16_t;
typedef int int32_t;
typedef unsigned int uint32_t;

#define MLA(a, m, n) (int32_t)((uint32_t)(a) + (uint32_t)((int32_t)(int16_t)(m)
* (int32_t)(int16_t)(n)))

int32_t bar(int32_t a, int32_t b);

int32_t foo(const int16_t *in, const int16_t *b)
{
  uint32_t x;

  x = bar(in[0], b[0]);

  x = MLA(x, in[-1], b[1]);
  x = MLA(x, in[-2], b[2]);
  x = MLA(x, in[-3], b[3]);
  x = MLA(x, in[-4], b[4]);
  x = MLA(x, in[-5], b[5]);

  return x;
}

$ clang --target=arm-linux-androideabi -march=armv7-a -mthumb
-fomit-frame-pointer -O3 -S /tmp/b.c -o -
[...]
foo:
        .fnstart
@ %bb.0:                                @ %entry
        .save   {r4, r5, r7, lr}
        push    {r4, r5, r7, lr}
        mov     r4, r1
        mov     r5, r0
        ldrsh.w r1, [r1]
        ldrsh.w r0, [r0]
        bl      bar
        ldr     r2, [r5, #-4]
        ldr.w   r3, [r4, #2]
        ldr     r1, [r5, #-8]
        ldr.w   r5, [r4, #6]
        smlabt  r0, r3, r2, r0
        smladx  r0, r3, r2, r0
        smladx  r0, r5, r1, r0
        pop     {r4, r5, r7, pc}
.Lfunc_end0:
        .size   foo, .Lfunc_end0-foo
        .cantunwind
        .fnend


My ARM/Thumb is rusty, but it appears that both the SMLABT and the first SMLADX
instruction are accumulating in[-1] * b[1] into r0, and that in[-5] and b[5]
are never even loaded.

-- 
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/20190821/27f83306/attachment.html>