[llvm-bugs] [Bug 24545] New: [x86] Silly code generation for _addcarry_u32/_addcarry_u64
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Aug 21 22:20:28 PDT 2015
https://llvm.org/bugs/show_bug.cgi?id=24545
Bug ID: 24545
Summary: [x86] Silly code generation for
_addcarry_u32/_addcarry_u64
Product: libraries
Version: 3.7
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedbugs at nondot.org
Reporter: myriachan at gmail.com
CC: llvm-bugs at lists.llvm.org
Classification: Unclassified
x86 intrinsics _addcarry_u32 and _addcarry_u64 generate silly code. For
example, the following function to get the result of a 64-bit addition (the XOR
is to the output clearer):
u64 testcarry(u64 a, u64 b, u64 c, u64 d)
{
u64 result0, result1;
_addcarry_u64(_addcarry_u64(0, a, c, &result0), b, d, &result1);
return result0 ^ result1;
}
This is the code generated with -O1, -O2 and -O3:
xor eax, eax
add al, -1
adc rdi, rdx
mov qword ptr [rsp - 8], rdi
setb al
add al, -1
adc rsi, rcx
mov qword ptr [rsp - 16], rsi
xor rsi, qword ptr [rsp - 8]
mov rax, rsi
ret
The first silliness is that _addcarry_u64 does not optimize a compile-time
constant 0 being the first carry parameter. Instead of "adc", it should just
use "add".
The second silliness is with the use of r8b to store the carry flag, then using
"add r8b, -1" to put the result back into carry.
The third silliness is that _addcarry_u64 is taking its pointer parameter too
literally; it shouldn't be storing values to memory at all.
Instead, the code should be something like this:
add rdx, rdi
mov rax, rdx
adc rcx, rsi
xor rax, rcx
ret
Naturally, for something this simple, I'd use unsigned __int128, but this came
up in large number math.
Cross-filed with GCC (with different generated code since it's a different
compiler =^-^=):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317
--
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/20150822/032ca71c/attachment.html>
More information about the llvm-bugs
mailing list