[Webkit-unassigned] [Bug 190208] clang Linux build cannot link because of __builtin_mul_overflow

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=190208

--- Comment #4 from Loïc Yhuel <loic.yhuel at softathome.com> ---
I compiled a simple C source file (outside WebKit) using __builtin_mul_overflow with 32 or 64 bit arguments.

arm-linux-gnu-gcc 8.1.1 :
 - 32 bit arguments : optimized code using smull
 - 64 bit arguments : complex code
aarch64-linux-gnu-gcc 8.1.1 :
 - 32 bit arguments : optimized code using smull, similar to ARM
Clang 7.0 ARM :
 - 32 bit arguments : optimized code, but using mul + smmul (might be slower than gcc)
 - 64 bit arguments : call __mulodi4
Clang 7.0 AArch 64 :
 - 32 bit arguments : optimized code, using smull
 - 64 bit arguments : optimized code using mul + smulh

gcc x86 (-m32) :
 - 32 bit arguments : optimized code, using imul and testing overflow flag
 - 64 bit arguments : complex code
gcc x86_64 :
 - 32 bit arguments : optimized code, using imul and testing overflow flag
 - 64 bit arguments : optimized code, using imul and testing overflow flag
Clang 7.0 x86 (-m32) :
 - 32 bit arguments : optimized code, using imul and testing overflow flag
 - 64 bit arguments : call __mulodi4
Clang 7.0 x86_64 :
 - 32 bit arguments : optimized code, using imul and testing overflow flag
 - 64 bit arguments : optimized code, using imul and testing overflow flag

tl,dr :
 - for 32 bit arguments, Clang should be OK (even if the ARM implementation is perhaps worse than gcc, it should be better than the C)
 - for 64 bit arguments, Clang cannot produce the code so calls __mulodi4 on 32-bit architectures

So :
 - we probably need to keep using the builtin with Clang on 32-bit architectures for the 1st and 2nd case if the arguments are 32-bit (so we need more template specializations)
 - we need to check if the compilers are able to use the 32-bit builtin for the 3rd case (int, unsigned specialization) in the code

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181002/002ba34c/attachment.html>