Upgrade to LLVM 3.9

[StefanKarpinski]

Related but closed: #18863. What's the status of this?

[vchuravy]

#19054 had the important bits and pieces of #18863 and from what I can tell we need:

• Patch llvm-3.8.0_threads for 3.9 Add Windows patches for LLVM 3.9 #19138
• Patch llvm-win64-reloc-dwarf for 3.9 (also Add Windows patches for LLVM 3.9 #19138 but may need double-checking)
• CMake >= 3.4.3 on Travis (done in RFC: Change LLVM version to 3.9.1 #19678)
• Update buildbots (see Upgrade cmake on all buildbots JuliaCI/julia-buildbot#54)
• Homebrew tap (see merge bottled llvm39-julia to master staticfloat/homebrew-julia#229)

[tkelman]

• make sure tests pass everywhere (seems obvious, but last I checked 3.8 they didn't - see backtraces in Add Windows patches for LLVM 3.9 #19138, neither win32 nor win64 can bootstrap successfully with 3.9 yet) fixed by Disable szclass 12 for i686 systems. #19647
• update appveyor binaries (see https://github.com/JuliaLang/julia/pull/14623/files for what this looked like last time - done in RFC: Change LLVM version to 3.9.1 #19678)
• add a script in contrib to make it easier for people on Linux to get a new cmake if their distro doesn't have one (nice-to-have, I'll write this - Add a script in contrib to download a cmake binary #19632)

[tkelman]

Note that the threads patch was initially borrowed from rust (who have the same toolchain C++11 threads issue we do with mingw), so we should check if they have a rebased version we could use to save ourselves a bit of time there. (edit: they do)

[vchuravy]

Something else I just noticed is that the Intel Compiler 2016_update2 is not able to build llvm. See https://sft.its.cern.ch/jira/browse/ROOT-8233 and https://software.intel.com/en-us/forums/intel-c-compiler/topic/640702

[tkelman]

Looks like that's icc's bug, but llvm continues to do an incredible job of finding new ways to break every other compiler...

[ihnorton]

Note that the threads patch was initially borrowed from rust (who have the same toolchain C++11 threads issue we do with mingw)

Worth keeping an eye on: https://github.com/lhmouse/mcfgthread

There was some discussion on the gcc list in April, but I don't see any response or recent activity, so it is unclear if/when it might go in to mainline. There is some further discussion/development on mingw-w64-public.

lhmouse does have a forked toolchain build here.

(related: https://github.com/meganz/mingw-std-threads -- header-only, but does not implement call_once std::async, and a handful of other things. call_once was the only issue I encountered when I tried building LLVM against it a while back)

[tkelman]

Yes, though unless that somehow gets backported to gcc 4, we'll need to worry about https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333... or come up with a proper fix to gmp's build system so it works with clang on windows and start using that (ref #15488 which doesn't work in cross-compile).

[Keno]

Another issue we'll start seeing is that LLVM symbols conflict with graphics drivers on Linux distributions that have (stupidly) chosen to dynamically link LLVM into their graphics drivers. I have a patch (https://reviews.llvm.org/D13330) that adds capabilities to clang, to avoid generating the problematic symbols, but I doubt similar capabilities will make it into gcc anytime soon.

[kpamnany]

Does this work at all on Linux? Need LLVM 3.9 to start testing Julia performance on KNL.

[yuyichao]

Stock/patched LLVM 3.9.0 should work with no problem on x86/x64 linux.

[andreasnoack]

@kpamnany I had to use LLVM-svn on KNL but it worked fine (~a month ago.)

[yuyichao]

@kpamnany Apply https://reviews.llvm.org/D26123 or a commit before https://reviews.llvm.org/rL285426 if you want a llvm-svn build without assertion enabled.