[llvm-bugs] [Bug 48826] New: Optimization for min(max) or max(min) pattern in ARM backend generates wrong calculate result

[via llvm-bugs]

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

            Bug ID: 48826
           Summary: Optimization for min(max) or max(min) pattern in ARM
                    backend generates wrong calculate result
           Product: libraries
           Version: trunk
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: yabinc at google.com
                CC: llvm-bugs at lists.llvm.org, smithp352 at googlemail.com,
                    Ties.Stuij at arm.com

With patch https://reviews.llvm.org/D87457?id=292224, clang generates wrong
calculation results in some cases:

A case to reproduce the bug is in https://godbolt.org/z/97W36o. The operation
list is
like below:
int8 output[];
int16 a = ?;
int16 b = ?;
a += b;
a = min(a, INT8_MAX);
a = max(a, INT8_MIN);
output[i] = a;

It is translated into below assembly:

lsr.w r11, r10, #16
add r0, r11
ssat r0, #8, r0
strb r0, [r6], #1


If a = 145, b = -128, then the correct output[i] should be 17. But here r11 is
using lsr.w to logical shift right,
using zero instead of sign extension to fill the high 16-bit. So it will
overflow and generates a wrong result 127.

In a real example on Android, ldrh.w is used instead of lsr.w, it also uses
zero extension instead of signed extension,
and generates a wrong result.

Before the patch, there is a sxth instruction between the add instruction and
the strb instruction, to make the result
correct. But after the patch, sxth instruction is gone.

-- 
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/20210121/e1dd5445/attachment-0001.html>