Slow division on ARM Linux/GNU

[MagaTailor]

The amicable numbers benchmark is slow on ARM again.

With a properly patched LLVM it used to perform like this:

samples  %        linenr info                 image name               symbol name
22510    85.9652  (no location information)   libgcc_s.so.1            /lib/arm-linux-gnueabihf/libgcc_s.so.1
3552     13.5650  amicable.rs:18              amicable.old             $a.0
99        0.3781  (no location information)   no-vmlinux               /no-vmlinux
3         0.0115  (no location information)   ld-2.19.so               .udivsi3_skip_div0_test
3         0.0115  dl-lookup.c:82              ld-2.19.so               do_lookup_x

whereas now, it's slow again:

samples  %        linenr info                 image name               symbol name
14943    32.5989  (no location information)   amicable                 __udivmodsi4
13260    28.9273  (no location information)   amicable                 __divmodsi4
9504     20.7334  (no location information)   amicable                 __aeabi_idivmod
7993     17.4371  amicable.rs:18              amicable                 $a.0
118       0.2574  (no location information)   no-vmlinux               /no-vmlinux
5         0.0109  dl-reloc.c:154              ld-2.19.so               _dl_relocate_object
3         0.0065  dl-lookup.c:82              ld-2.19.so               do_lookup_x

LLVM doesn't need patching anymore so it must have been the compiler-rt removal, etc.

[est31]

so it must have been the compiler-rt removal, etc.

Just noting, compiler-rt is not removed yet, its only "crate-ified", so that its build system uses a build.rs now. But its still compiling the source files of the original compiler-rt.

[parched]

@MagaTailor which arm target are you testing? And which two compiler versions?

[MagaTailor]

llvm.org/viewvc/llvm-project?view=revision&revision=259657

[MagaTailor]

I have no idea if it ever worked for any officially distributed builds and the earliest broken build of mine still lying around is dated 16eeeac78 2016-10-18. IIRC, LLVM 3.9 did include that patch so the issue should have gone away.

Anyone wishing to find out can use this build as a working baseline.

[MagaTailor]

The issue is not present in clang 4.0 so it's definitely another rust fuckup.

[parched]

Hi @MagaTailor, if you can provide some more details on how reproduce this, I will investigate. Can you give both the C code and Rust code you are comparing, along with the exact compiler switches you are using and what target you are testing on?

[MagaTailor]

https://pastebin.com/X3ZTp1c0

[parched]

Thanks, and what compiler switches and what target?