<div dir="ltr"><div>Reviewers: me, Simon Pilgrim, Sanjay Patel(the 3 most active X86 contributors) and probably Steve Canon since he wrote the original routines.</div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 3, 2018 at 10:51 AM Stefan Kanthak <<a href="mailto:stefan.kanthak@nexgo.de">stefan.kanthak@nexgo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"Craig Topper" <<a href="mailto:craig.topper@gmail.com" target="_blank">craig.topper@gmail.com</a>> wrote:<br>
<br>
> None of the "si" division routines will be used by x86.<br>
<br>
That was my expectation too.<br>
<br>
> They exist for targets that don't support the operations natively.<br>
> X86 supports them natively so will never use the library functions.<br>
<br>
So they SHOULD not be built (or at least not shipped) with the<br>
builtins library for x86.<br>
<br>
> X86 has its own assembly implementation of __muldi3 that uses 32-bit<br>
> pieces.<br>
<br>
I know; that's why I placed this ABOVE my "JFTR:"<br>
<br>
> We should be using the assembly versions of the "di" division routines on<br>
> i386. Except when compiler-rt is built with MSVC because MSVC can't parse<br>
> the at&t assembly syntax.<br>
<br>
Again: my offer to provide these routines still stands!<br>
<br>
I have OPTIMISED __divdi3, __moddi3, __udivdi3 and __umoddi3 in<br>
Intel syntax, wrapped as inline files into an NMakefile, for use<br>
with ML.EXE.<br>
For the optimisations see the patch I sent last week.<br>
<br>
Since Howard Hinnant is NO MORE with LLVM: who is the CURRENT<br>
code owner and reviewer for the builtins library, especially for<br>
x86?<br>
<br>
I'm asking this SIMPLE question now for the 3rd time!<br>
<br>
I also have __udivmoddi3: adding the pointer to the remainder as<br>
argument and 4 more instructions will turn it into __udivmoddi4.<br>
<br>
Compiling them with MSVC is of course easy to achieve: remove the<br>
MASM/ML statements, put the assembler source inside an __asm block,<br>
and add a function definition with __declspec(naked)<br>
<br>
But then someone will have to find new filenames; I'd prefer to<br>
leave them as *.ASM, so they can be added to YOUR source tree<br>
without clobbering existing files.<br>
<br>
The same holds for __alldiv, __alldvrm, __allrem, __aulldiv,<br>
__aulldvrm and __aullrem, plus __allmul, __allshl, _allshr and<br>
__aullshr.<br>
<br>
If you name a reviewer I'll send them to llvm-commits!<br>
<br>
regards<br>
Stefan<br>
<br>
> On Mon, Dec 3, 2018 at 5:51 AM Stefan Kanthak via llvm-dev <<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
>> 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>
>><br>
><br>
</blockquote></div>