llvm-7.0.0

[Douglas R. Reno]

New major version

[ken@…]

Just a note that it works for me, and because I have Sphinx installed I used ninja to build the docs.

That saves having to wipe out the build. I used

cmake -DLLVM_ENABLE_SPHINX=ON         \
      -DSPHINX_WARNINGS_AS_ERRORS=OFF \
      -Wno-dev -G Ninja ..
ninja ${NINJAJOBS} docs-llvm-html docs-llvm-man
ninja ${NINJAJOBS} docs-clang-html docs-clang-man

and then install the various docs as we do now. This probably also saves a little time because ninja runs a couple of jobs at the same time.

[carys]

I works for me also just fine and i will upload the patch file for the new xml file for llvm.

I would like to note that much more tests fail now (343 out of 43514). They are still test failures related to the Sanitizer.

[ken@…]

Looking at the patch, there are a couple of things I disagree with (I have NOT run tests).

First, the SBU seems "somewhat large" for a -j4 build. On a Ryzen 3, wITH (minimal) docs I got 21.1 SBU (rounds to 21). On an intel machine where single-threading is fast and parallel is slow, I would expect a higher figure, but not that big.

Second, the installed programs have changed: Looking at my log, I notice that clang-cppi is mentioned in the current book, obviously a typo for clang-cpp. The following programs are not mentioned: clang-func-mapping, clang-refactor, diagtool, dsymutil, hmaptool, llvm-cfi-verify, llvm-exegesis, llvm-mca, llvm-objcopy, llvm-rc.

No longer present: llvm-dsymutil (probably dsymutil replaces it), llvm-mcmarkup, llvm-strip, llvm-undname.

[ken@…]

More (interim) comments. I'm back on my i7 haswell running measurements. I had thought I could use a patched ninja to just run 4 jobs - worked on running 4 jobs across 8 random cores for the build, but running the tests used 8 threads, so I stopped that.

Before the tests I had done a DESTDIR, the space used was 2.3GB source and 670MB installed, or 2.9GB and it rounded to 25 SBU (for measuring, I do not interfere with CFLAGS).

Currently doing a build with taskset limiting it to CPUs 2,3,6,7 i.e. hyperthreading and it is taking a LOT longer, maybe your figure was hyperthreaded ?

Once that finishes I'll run the tests, then perhaps repeat with 4 prime CPUs.

[ken@…]

For building the tests, all (available) cores are now used, not just one. For running the tests, a thread is scheduled for all physical cores (even if not available to the process), so I think this is going to take a long time ;-)

[ken@…]

/me swears at track for discarding what I had written. Retrying:

Tests finished quicky, despite using 8 cores out of two available hyperthreaded cores. That took 17 SBU (seriously slow, as expected). I also noticed one reported failure from trying to link-static and not finding libstdc.a so I have made that and its friend libstdc++fs.a available.

But only 9 failures

ken@plexi /scratch/ken/llvm-7.0.0.src/build $grep '^FAIL' testlog-2367
FAIL: AddressSanitizer-x86_64-linux :: TestCases/throw_invoke_test.cc (3841 of 43590)
FAIL: AddressSanitizer-x86_64-linux-dynamic :: TestCases/throw_invoke_test.cc (4274 of 43590)
FAIL: LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/use_tls_dynamic.cc (41559 of 43590)
FAIL: LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/use_tls_dynamic.cc (41604 of 43590)
FAIL: MemorySanitizer-X86_64 :: Linux/sunrpc.cc (41642 of 43590)
FAIL: MemorySanitizer-X86_64 :: Linux/sunrpc_bytes.cc (41643 of 43590)
FAIL: MemorySanitizer-X86_64 :: Linux/sunrpc_string.cc (41646 of 43590)
FAIL: MemorySanitizer-X86_64 :: dtls_test.c (41670 of 43590)
FAIL: ThreadSanitizer-x86_64 :: sunrpc.cc (42923 of 43590)
FAILED: CMakeFiles/check-all 

FWIW I agree about 16 GB extra for the tests, and the SBU for build and DESTDIR with two pairs of hyperthreaded cores was 37 SBU.

Will remind myself how to take the hyperthreaded siblings offline to use only the primary cores, as if on an i5 of the same generation.

[ken@…]

Replying to ken@…:

No longer present: llvm-dsymutil (probably dsymutil replaces it), llvm-mcmarkup, llvm-strip, llvm-undname.

In fact llvm-strip and llvm-undname ARE still present.

[ken@…]

Results with only 4 primary cores online:

Build and DESTDIR rounds to 26 SBU. Tests round to 7.9 SBU but since there is so much range I am inclined to call it 8.0 SBU.

Only seven failures:

ken@plexi /scratch/ken/llvm-7.0.0.src/build $grep '^FAIL' testlog-1234 
FAIL: LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/use_tls_dynamic.cc (41555 of 43590)
FAIL: LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/use_tls_dynamic.cc (41596 of 43590)
FAIL: MemorySanitizer-X86_64 :: Linux/sunrpc.cc (41645 of 43590)
FAIL: MemorySanitizer-X86_64 :: Linux/sunrpc_bytes.cc (41646 of 43590)
FAIL: MemorySanitizer-X86_64 :: Linux/sunrpc_string.cc (41647 of 43590)
FAIL: MemorySanitizer-X86_64 :: dtls_test.c (41673 of 43590)
FAIL: ThreadSanitizer-x86_64 :: sunrpc.cc (42927 of 43590)
FAILED: CMakeFiles/check-all 

[ken@…]

I've got skeletal explanations for the new programs (and -strip and -undname are in fact new: too many progs with weird or mickeysoft names in this package). Will take it.

[ken@…]

r20553