Targeted LLVM for 1.0

[fabiand]

Indeed. I think it’s quite important to let rust use some existing llvm build. As pointed out in the past, this is crucial to get rust into distros like Fedora (which has a rather strict policy). But getting support from distros might really help rust to get spread among Linux developers.

[alexcrichton]

As @brson mentioned, I think it would actually be pretty simple to work with basically LLVM 3.4+ (maybe even 3.3). All custom bits we have are optimizations or extra platform support (as @brson mentioned) and are not crucial to codegen on major platforms.

I suspect that any update needed to be compatible with LLVM 3.x is just a typedef away in RustWrapper.cpp or one of our other bindings. To really provide “official support” though we would need to gate on builders buliding against various LLVM versions, which may not necessarily happen for 1.0.

[lucab]

Thanks for all the replies. Yes, I saw that the delta with upstream LLVM is nowadays mostly optimization stuff and I didn’t meant to touch that topic.

My question was if we still wanted to retain compatibility with several (stable) LLVM, and the answer seems yes. Debian is defaulting to 3.5 and the C++ wrapper seems minimal enough that I can give it a quick patching. However, I’m not sure about the assume intrinsic exposed in rust and related tests: this will fail on 3.5 and makes the language dependent on the underlying LLVM version in use. How would you like to handle that?

[sanxiyn]

Rust already has a mechanism to handle LLVM version-dependent intrinsics.

[ahmedcharles]

Has anyone tried moving the patches upstream?

[lucab]

@sanxiyn thanks a lot, I was exactly missing that piece of information!

@ahmedcharles yes, the process is ongoing since some time and the delta right now is minimal (at least compared to some year ago), kudos to @brson and @alexcrichton for that. (and I was not inquiring on that)

[nagisa]

As @brson mentioned, I think it would actually be pretty simple to work with basically LLVM 3.4+ (maybe even 3.3).

Glorious Haskell Compiler disagrees. We possibly really want to only have only one (officially) supported LLVM version at a time.

[Ericson2314]

Based on these comments and the GHC wiki, maybe depending on stock 3.6 is the way to go? Especially if that is released before our 1.0.

[lucab]

A small update from our (as in debian packagers) side:

• we patched curent rust to build with packaged LLVM-3.5, but rustc goes ICE in the middle of stage2
• we packaged the recently tagged 3.6-rc1, but API changed in the meanwhile so rust fails to build with it
• we tried 3.4 as a last resort fallback, but from a quick glance the number of API changes would require invasive patching to RustWrapper.cpp (I can post the build errors if anybody is interested in it)

As a result, rust is currently locked to its embedded LLVM fork (somewhere in-between 3.5 and 3.6-rc1) From my point of view, it would make sense to rebase now the embedded LLVM fork to something closer to 3.6-rc1, to be at least ready for next stable LLVM. Then, if we want to keep 3.5, we can further dig in the ICE. I can’t quantify the amount of patching needed to keep 3.3/3.4 alive, but I have the feeling it may not worth it (personally, we won’t be using them).

[FlaPer87]

FWIW, I think we should have support for a range of stable llvm releases. The reason for this is that it’d be really nice for Rust to be shipped in existing LTS versions of some distros. Fedora 21 currently ships llvm 3.5, whereas in RHEL there’s a quite older version.

I agree with @lucab on trying to be fully compliant with 3.6 and hopefully make Rustc work with 3.5. I believe we should eventually get to the point where we can just remove our fork completely.

[tshepang]

If Rust is to be shipped with an already-released distro, then that distro may as well ship a newer LLVM. I think that packaging a newer LLVM would be a far easier job than packaging Rust (from scratch). That’s because LLVM already exists in distros, and needs only an update (or a backport).

[Ericson2314]

@tshepang That’s a great point

[FlaPer87]

@tshepang I’m afraid that’s not correct, unfortunately.

Distros, especially stable releases with LTS, have strict policies when it comes to maintaining software and pulling in newer versions for any package that is supposed to be maintained.

Also, nota that the suggestion is not to make Rust work with way older versions of llvm. I believe 3.4/3.5 are versions that it’d be worth to support, if possible.

One more thing to keep in mind is that this is not an issue we’ll have just for 1.0. In every single release we’ll have to check what versions of llvm are (will be) supported in order to be able to provide long term support for stable releases and possible backports.

[tshepang]

My response was based on you saying it’d be really nice for Rust to be shipped in existing LTS versions of some distros. By shipping, I assumed you meant packaged? If not, what did you mean?

[FlaPer87]

I did mean packaged. However, I also said we shouldn’t go way back in versions. For instance, Ubuntu Trusty (LTS) has support for llvm 3.4, Fedora 21 has support for 3.5 and RHEL has support for 3.2. While I don’t think we should go back to 3.2 (regardless of whether we’ll be able to do something in RHEL), I do think having support for 3.5 and 3.4 if possible is a worth thing to try and aim for.

[tshepang]

So, how would Rust be packaged in an already-released distro, but a newer LLVM not?

[naicode]

Because they have already decided witch version of witch compiler will be mainly supported by the LTS release date. And due to the large amount of software relaying on the specific version they cannot change this in the mid. (You could still e.g include a specific llvm version in the rust package but this would blow up it’s size)

[tshepang]

The newer LLVM doesn’t have to be the default, so it would break nothing. It would be packaged just to be a build dependency of Rust (and whatever else may later require such a version). So, the question remains… why would a distro accept Rust (a brand new package) but not a newer LLVM (an update/backport)?

[sylvestre]

As the Debian & Ubuntu maintainer of the LLVM toolchain and working on the rust packaging with Luca, I don’t think you should bother to maintain rust with too many version of LLVM. Doing it for a single release is already an hard task by itself. Having 3.6 (the next major upstream release) would be a first good step. Distro interested to backport Rust will also backport the LLVM version.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.