Updating Rust 1.19 to LLVM 4.0.1

[arielb1]

LLVM 4.0.0, which we upgraded to in Rust 1.19 (currently beta, due Jul 21 2017), seems too have quite a few bugs in non-x86 architectures (e.g. ARM).

Many of these bugs are fixed on LLVM’s trunk (of course, we can’t update to the trunk directly, because it has many new bugs). I backported a few of these fixes to our fork.

Similarly, LLVM’s maintainers have backported 21 of these fixes to LLVM 4.0.1:

[mips][mc] Fix a crash when disassembling odd sized sections
Use correct registers for "A" inline asm constraint
[X86] Remove special handling for 16 bit for A asm constraints.
Fix invalid addrspacecast due to combining alloca with global var
Adding const overloads of operator* and operator-> for DenseSet iterators
[Hexagon] Fix lowering of formal arguments of type i1
[InstCombine] Fix bug in pointer replacement
[CMake] Fix pthread handling for out-of-tree builds
CMake: Don't install llvm-tblgen twice
[MemCpyOpt] Only replace memcpy with bitcast if address spaces match
[ArgPromotion] Fix a truncated variable
[safestack] Disable stack coloring by default
merge-request.sh: Use https url for bugzilla
[ARM] Clear the constant pool cache on explicit .ltorg directives
[ARM] Temporarily disable globals promotion to constant pools to prevent miscompilation
[TLI] Add prototype checking for all remaining LibFuncs
[PPC] Properly update register save area offset
[PPC] When restoring R30 (PIC base pointer), mark it as <def>
Make library calls sensitive to regparm module flag (Fixes PR3997).
[GlobalMerge] Don't merge globals that may be preempted
[Support] Fix ErrorOr assertion when /proc/cpuinfo doesn't exist.

The [ARM] Temporarily disable globals promotion to constant pools to prevent miscompilation patch fixes https://github.com/rust-lang/rust/issues/42893, and a few of the other patches look like miscompilation fixes. I’m probably going to backport that patch to 1.19, because it fixes a codegen regression we’ve seen ourselves, but I’m also thinking we should backport 4.0.1 in its entirety.

Does that sound like something we should do? Did we miss the 1.19 opportunity, but should backport it to 1.20 and similarly for 5.0.1 when we upgrade the LLVM 5.0? Any other options?

[alexcrichton]

I’d say let’s upgrade to 4.0.1, and backporting this to 1.19 seems reasonable to me as well.

[gnzlbg]

Would it be possible for us to just follow LLVM trunk on nightlies and then use whatever LLVM version nightly had when switching it to beta and stable?

[sanxiyn]

Anything is possible, but LLVM trunk is considerably more unstable than LLVM release branches.

[gnzlbg]

But wouldn’t it be less work to fix breakage as it happens instead of doing so all at once every 6 months?

Also, bug wise, wouldn’t it be better for us to catch LLVM bugs as they happen, and report them as quickly as possible so that the next releases won’t contain them?

[binarycrusader]

Speaking as a port maintainer and from experience, no you really don’t want to use LLVM nightly. Not only is it like trying to drink water from a firehose, it makes debugging very frustrating. You’re far better off synchronizing with each release than dealing with all the breakage in between, at least for standard gate development. Now, it might be perfectly sensible to do a nightly build based on nightly LLVM in an automated fashion for informative purposes, but I would discourage forcing that cost on all other developers.