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: unassignedb...@nondot.org
Reporter: yab...@google.com
CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com,
ties.st...@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
