<div dir="ltr">None of the "si" division routines will be used by x86. They exist for targets that don't support the operations natively. X86 supports them natively so will never use the library functions.<div><br></div><div>X86 has its own assembly implementation of __muldi3 that uses 32-bit pieces.</div><div><br></div><div>We should be using the assembly versions of the "di" division routines on i386. Except when compiler-rt is built with MSVC because MSVC can't parse the at&t assembly syntax.</div><div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 5:51 AM Stefan Kanthak via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi @ll,<br>
<br>
LLVM-7.0.0-win32.exe contains and installs<br>
lib\clang\7.0.0\lib\windows\clang_rt.builtins-i386.lib<br>
<br>
The implementation of (at least) the multiplication and division<br>
routines __[u]{div,mod,divmod,mul}[sdt]i[34] shipped with this<br>
libraries SUCKS: they are factors SLOWER than even Microsoft's<br>
NOTORIOUS POOR implementation of 64-bit division shipped with<br>
MSVC and Windows!<br>
<br>
The reasons: 1. subroutine matroschka, 2. "C" implementation!<br>
<br>
JFTR: the target processor "i386" (introduced October 1985) is<br>
      a 32-bit processor, it has instructions to divide 64-bit<br>
      integers by 32-bit integers, and to multiply two 32-bit<br>
      integers giving a 64-bit product!<br>
      I expect that a library written 20+ years later takes<br>
      advantage of these instructions!<br>
<br>
__divsi3 (18 instructions) perform a DIV after 2 calls of abs(),<br>
                           plus a final negation, instead of just<br>
                           a single IDIV<br>
__modsi3 (14 instructions) calls __divsi3 (18 instructions)<br>
__divmodsi4 (17 instructions) calls __divsi3 (18 instructions)<br>
<br>
__udivsi3 (52 instructions) does NOT use DIV, but performs BITWISE<br>
                            division using shifts and additions!<br>
__umodsi3 (14 instructions) calls __udivsi3 (52 instructions)<br>
__udivmodsi4 (17 instructions) calls __udivsi3 (52 instructions)<br>
<br>
__muldi3 (41 instructions) performs a "long" multiplication on<br>
                           16-bit "digits"<br>
<br>
JFTR: I haven't checked whether clang actually calls these<br>
      SUPERFLUOUS routines listed above.<br>
      IT BETTER SHOULD NOT, NEVER!<br>
<br>
__divdi3 (37 instructions) calls __udivmoddi4 (254 instructions)<br>
__moddi3 (51 instructions) calls __udivmoddi4 (254 instructions)<br>
__divmoddi4 (36 instructions) calls __divdi3 (37 instructions) which<br>
                              calls __udivmoddi4 (254 instructions)<br>
__udivdi3 (8 instructions) calls __udivmoddi4 (254 instructions)<br>
__umoddi3 (33 instructions) calls __udivmoddi4 (254 instructions)<br>
<br>
JFTR: the subdirectory compiler-rt/lib/builtins/i386/ contains FAR<br>
      better (although suboptimal) __divdi3, __moddi3, __udivdi3 and<br>
      __umoddi3 routines written in assembler, which SHOULD be<br>
      shipped with clang_rt.builtins-i386.lib instead of the above<br>
      listed POOR and NOT optimised implementations!<br>
<br>
NOT AMUSED<br>
Stefan Kanthak<br>
<br>
PS: <<a href="https://lists.llvm.org/pipermail/llvm-dev/2018-November/128094.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2018-November/128094.html</a>><br>
    has patches for the assembler routines!<br>
<br>
PPS: please remove the blatant lie<br>
     | The builtins library provides optimized implementations of<br>
     | this and other low-level routines, either in target-independent<br>
     | C form, or as a heavily-optimized assembly.<br>
     seen on <<a href="https://compiler-rt.llvm.org/" rel="noreferrer" target="_blank">https://compiler-rt.llvm.org/</a>><br>
     These routines are NOT optimized, and for sure NOT heavily-<br>
     optimized!<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>