Phase out LLVM versions older than 5.0.0 ?

[gnzlbg]

With the current push for SIMD intrinsics, nigthly Rust already relies on a bunch of intrinsics that are only available in LLVM 5, 6, and some which are only bug-free on LLVM 7. Stable features like target_feature/cfg_target_feature also don't really work properly with older LLVMs (they require at least LLVM 6 IIRC, cc @alexcrichton).

These are the release dates of the most recent LLVM versions:

16 May 2018 | LLVM 5.0.2
8 Mar 2018 | LLVM 6.0.0
21 Dec 2017 | LLVM 5.0.1
07 Sep 2017 | LLVM 5.0.0
04 Jul 2017 | LLVM 4.0.1
13 Mar 2017 | LLVM 4.0.0

Supporting an LLVM that is at least two releases old appears reasonable to me: with LLVM 7 being released in August this would mean that maybe we can bump the minimum version to LLVM 5.0.x.

I'd like to ask stakeholders to please chime in and mention which LLVM versions they are currently shipping Rust with, and what would be the minimum version that it would make sense for them.

cc @cuviper @rkruppe

[gnzlbg]

cc @infinity0 @aidanhs @est31

[cuviper]

• Fedora Rawhide has LLVM 6.0.1 (not official yet, but @tstellar is both packager and release manager)
• Fedora 28 has LLVM 6.0.0, will get 6.0.1 soon
• Fedora 27 has LLVM 5.0.2
• EPEL7 (extras for RHEL7) has LLVM 5.0.1
• For Red Hat SCLs, rust-toolset uses llvm-toolset, currently at 5.0.1

So LLVM 5 would be fine for me.

[alexcrichton]

We've never really had a strict policy about what LLVM versions to support or what it even means to "support" an older version of LLVM. Most of the time the stock LLVM releases never pass our full test suite on all the platforms (but very often pass the full x86_64 linux suite). Stock LLVM releases tend to also quite commonly miss out on backports to fix bugs and/or otherwise fix performance issues as well.

For all those reasons I personally view our support of stock older LLVM releases as pretty nebulous. There's already a good deal of functionality that doesn't work per se or will break on "flavorful programs". I'd personally be totally fine to lump in SIMD with these releases as well.

All that being said though I don't have any problems dropping support for pre-5.0 versions either!

[cuviper]

src/llvm-emscripten is still on LLVM 4 -- do we have a plan to update or abandon that?

[alexcrichton]

Ah that's an Emscripten-specific LLVM which doesn't deal with SIMD or distros really. We'll upgrade that entirely independently of other backends and we just track Emscripten upstream

[infinity0]

Debian rustc is on LLVM 6.0 and we typically have 5-15 failing tests on the most common architectures, so this seems fine for me.