https://bugs.llvm.org/show_bug.cgi?id=43922
Bug ID: 43922
Summary: [X86] some builtins generate incorrect code for shifts
with large (constant) shift counts
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected], [email protected]
Created attachment 22780
--> https://bugs.llvm.org/attachment.cgi?id=22780&action=edit
IR in question
The attached IR features a call to a builtin that generates a PSRAD
instruction. The shift count is large, and in such cases the instruction's
definition says that the result should be equal to the operand's sign bit (or
the sign bits of its respective elements) extended to the entire width of the
result (i.e. 0 or -1).
The instruction, however, is emitted with a shift count of 0, yielding a result
identical to the input operand.
movq .LCPI0_0(%rip), %mm0 # mm0 = 0x7AAAAAAA7AAAAAAA
psrad $0, %mm0
I do not think undefined behaviour is in play here, since I would expect that
the semantics of a builtin are directly derived from the that of the
instruction they represent, though I could be wrong about that.
The IR has been generated from the following C source:
// -----------------------------------------------------
typedef int __v2si __attribute__((__vector_size__(8)));
typedef long long __m64 __attribute__((__vector_size__(8)));
extern "C" int printf(const char *, ...);
int main()
{
__m64 id17152 = {(long long)0x7aaaaaaa7aaaaaaa};
int id17156 = 0x10000000;
__m64 id17151 = (__m64)__builtin_ia32_psradi((__v2si)id17152,
id17156);
printf("id17151 = %llx\n", id17151[0]);
}
// ------------------------------------------------------
gcc 7.4.0 prints 0 for this code.
In a late stage IR dump the PSRAD instruction shows up with the correct shift
count:
renamable $mm0 = MMX_PSRADri killed renamable $mm0(tied-def 0), 268435456
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
