Stream: t-compiler/wg-llvm

Topic: LLVM 10 upgrade


Nikita Popov (Jan 05 2020 at 16:03, on Zulip):

FYI I've started some work on upgrading on LLVM 10 in https://github.com/rust-lang/rust/pull/67759. Unfortunately things look quite bleak where compile-time is concerned.

cuviper (Jan 07 2020 at 22:50, on Zulip):

should we rebase on 9.0.1 in the meantime?

Nikita Popov (Jan 07 2020 at 23:02, on Zulip):

Sounds reasonable.

Alex Crichton (Jan 17 2020 at 19:45, on Zulip):

As a heads up, it looks like the wasm dwarf patches have landed in LLVM 10, so we won't need to rebase those

cuviper (Mar 19 2020 at 18:12, on Zulip):

@Nikita Popov can we get a PR with the latest LLVM 10 compatibility changes? I guess performance is still a concern for updating the submodule, but I will probably want to move rustc to LLVM 10 in Fedora soon anyway.

cuviper (Mar 19 2020 at 18:12, on Zulip):

I can cherry-pick into a new PR myself, if you like

Nikita Popov (Mar 19 2020 at 19:13, on Zulip):

@cuviper I've opened https://github.com/rust-lang/rust/pull/70163 with everything but the submodule update.

Nikita Popov (Mar 19 2020 at 19:20, on Zulip):

And yeah, I didn't have much luck figuring out what the compile-time issue is. If anyone else could take a poke at that, it would be great.

Nikita Popov (Mar 19 2020 at 19:24, on Zulip):

On the positive side, I got somewhat pissed about the the criminal negligence that LLVM has towards compile-time and have set up http://llvm-compile-time-tracker.com/ over the weekend. Maybe it will help to identify issues early.

cuviper (Mar 19 2020 at 19:59, on Zulip):

Thanks! I'll give that a spin locally and then r+

RalfJ (Mar 25 2020 at 15:37, on Zulip):

so how hard would it be to retroactively fill that website with data from the LLVM 10 dev cycle to maybe narrow down the regression?

cuviper (Mar 30 2020 at 21:43, on Zulip):
$ git log --oneline release/9.x..release/10.x | wc -l
17808
cuviper (Mar 30 2020 at 21:43, on Zulip):

seems hard to retroactively do all of that

cuviper (Mar 30 2020 at 21:44, on Zulip):

maybe it could be done like a bisection?

cuviper (Mar 30 2020 at 21:47, on Zulip):

but there's probably not one thing to zero in on -- more likely a lot of performance paper cuts

mark-i-m (Apr 01 2020 at 03:41, on Zulip):

Could it be bisected?

RalfJ (Apr 20 2020 at 22:11, on Zulip):

Looks like we are not the only ones suffering from LLVM getting slower:
https://lists.llvm.org/pipermail/llvm-dev/2020-April/140938.html

mark-i-m (Apr 25 2020 at 16:49, on Zulip):

Is it a viable path to just skip LLVM 10 altogether and hope that LLVM 11 has better perf?

mark-i-m (Apr 25 2020 at 16:50, on Zulip):

i.e. is that something we could actually consider, or does it have other technical problems?

cuviper (Apr 25 2020 at 17:01, on Zulip):

sure, I see no technical problem with that

cuviper (Apr 25 2020 at 17:01, on Zulip):

the rust repo supports LLVM 10 now

Amanieu (Apr 25 2020 at 17:56, on Zulip):

Well there's the fact that debuginfo for RISC-V is pretty broken in LLVM 9... It's fixed in LLVM 10.

mati865 (Apr 27 2020 at 09:29, on Zulip):

LLVM tends to optimise more and more. It's more likely LLVM 11 will be even slower than LLVM 10 than the opposite.
There is fairly recent comparison from Clang 6 to Clang 10(pre-release): https://openbenchmarking.org/result/1912190-HU-COREI759690 just hit ctrl+f and search for "Time To Compile".
More detailed Clang 9 vs Clang 10 (final): https://www.phoronix.com/scan.php?page=article&item=clang-10-benchmarks&num=4

mark-i-m (May 01 2020 at 03:57, on Zulip):

Hmm... well that's troubling trend.

mark-i-m (May 01 2020 at 03:58, on Zulip):

Is there a way to turn off llvm optimizations selectively? e.g. only keep optimizations that were enabled in llvm 9? then we could incrementally turn on the optimizations we want

Nikita Popov (May 02 2020 at 16:25, on Zulip):

Things are looking pretty good for LLVM 11 actually. We're down about 7-8% since I started measuring. Of course, no idea how well that will translate to Rust, which generates significantly different IR than clang.

nagisa (May 11 2020 at 00:00, on Zulip):

@Nikita Popov congrats on being almost at the top of HN!

nagisa (May 11 2020 at 00:09, on Zulip):

… and top now.

mark-i-m (May 11 2020 at 17:57, on Zulip):

@Nikita Popov Your blog post is excellent! And thanks for all your hard work. This is excellent :)

vertexclique (May 15 2020 at 12:35, on Zulip):

@Nikita Popov Hi Nikita, would like to ask that how can i help to incorporate Aarch64 TME extensions. Or is there a plan? I've checked out locally but I don't see any incorporations at the https://github.com/rust-lang/llvm-project/tree/rustc/10.0-2020-05-05

Nikita Popov (May 15 2020 at 12:56, on Zulip):

From what I see, TME support was added in https://github.com/llvm/llvm-project/commit/a36d31478c182903523e04eb271bbf102bfab2cc, which is part of LLVM 10.

vertexclique (May 15 2020 at 15:06, on Zulip):

Yes, after the upgrade I will open a pr against stdarch I presume.

Alex Crichton (May 19 2020 at 16:32, on Zulip):

@Nikita Popov FWIW I updated the container to 20.04 locally and it did indeed still fail, the error was a giant wall of text though but it did seem somewhat related to the lack of -std=... flags

Nikita Popov (May 19 2020 at 19:56, on Zulip):

@Alex Crichton Thanks for testing that. I've now worked around the issue by passing CMAKE_CXX_STANDARD from our side, though LLD should really be setting this itself. Fingers crossed that this is not going to be a long whack-a-mole again...

Alex Crichton (May 19 2020 at 20:25, on Zulip):

@Nikita Popov btw once this lands, mind gc'ing the old 10.0 branches which ended up getting unused?

Alex Crichton (May 20 2020 at 16:11, on Zulip):

@Nikita Popov hey wanna try to help debug this issue here?

Alex Crichton (May 20 2020 at 16:11, on Zulip):

may be faster than going through comments on a PR

Alex Crichton (May 20 2020 at 16:13, on Zulip):

the raw log of a build after updating to 20.04 indicates that this is the host build of LLVM, so not related to cross-compiles yet

Alex Crichton (May 20 2020 at 16:13, on Zulip):

I'm manually going into the container and reexecuting the c++ commands rather than updating the source

Alex Crichton (May 20 2020 at 16:14, on Zulip):

I threw on -H which apparently prints out header paths

Alex Crichton (May 20 2020 at 16:14, on Zulip):

and nothing comes from the host LLVM (if any), so all #include is coming from the build directory for LLVM

Alex Crichton (May 20 2020 at 16:14, on Zulip):

I see /checkout/obj/build/x86_64-unknown-linux-gnu/llvm/build/include/llvm/IR/IntrinsicEnums.inc included as well yeah

Alex Crichton (May 20 2020 at 16:15, on Zulip):

oh dear, I think I mixed up my build directories

Alex Crichton (May 20 2020 at 16:16, on Zulip):

ok I'm blowing things away and restarting

Nikita Popov (May 20 2020 at 16:18, on Zulip):

By the way, how did you manage to run the image in the first place? For me it gets stuck at "Configuring tzdata", because it expects user input.

Alex Crichton (May 20 2020 at 16:18, on Zulip):

ENV DEBIAN_FRONTEND noninteractive

Alex Crichton (May 20 2020 at 16:18, on Zulip):

right above the apt-get line

Alex Crichton (May 20 2020 at 16:19, on Zulip):

it's a bad hack :(

Nikita Popov (May 20 2020 at 16:20, on Zulip):

Thanks, that did it

Alex Crichton (May 20 2020 at 16:21, on Zulip):

FWIW the -std=c++11 flag was coming from llvm-config

Alex Crichton (May 20 2020 at 16:21, on Zulip):

but I'm pretty sure I built an older LLVM then updated the submodule and didn't rebuild

Alex Crichton (May 20 2020 at 16:21, on Zulip):

basically I got the submodules mixed up

Nikita Popov (May 20 2020 at 16:22, on Zulip):

Ah, so just updating the image might be sufficient after all?

Alex Crichton (May 20 2020 at 16:23, on Zulip):

it may be yeah

Alex Crichton (May 20 2020 at 16:23, on Zulip):

I'm re-running the build to confirm/deny that

Alex Crichton (May 20 2020 at 16:23, on Zulip):

I'm not certain I mixed up the submodules, but my submodule was definitely at not the commit I expected

Alex Crichton (May 20 2020 at 16:23, on Zulip):

I am now certain, however, it is correct

Alex Crichton (May 20 2020 at 16:34, on Zulip):

ok freebsd build of llvm is making progres

Alex Crichton (May 20 2020 at 16:35, on Zulip):

@Nikita Popov ok so I was wrong, updating to ubuntu 20.04 does not fix the llvm build

Alex Crichton (May 20 2020 at 16:35, on Zulip):

I must have accidentally switched back

Alex Crichton (May 20 2020 at 16:36, on Zulip):

it's the same error as before

Alex Crichton (May 20 2020 at 16:36, on Zulip):

I think this has to do with the freebsd toolchain itself

Alex Crichton (May 20 2020 at 16:36, on Zulip):

and how we assemble it

Alex Crichton (May 20 2020 at 16:37, on Zulip):

so I think we should just disable it and move on

Alex Crichton (May 20 2020 at 16:37, on Zulip):

cc'ing folks who might know how to rebuild it

Nikita Popov (May 20 2020 at 17:45, on Zulip):

@Alex Crichton I managed to get it to build with this patch: https://gist.github.com/nikic/1200fed33696d1622a4ec1f523d2e651

Nikita Popov (May 20 2020 at 17:47, on Zulip):

This uses LLVMs own vector implementation instead of the libc++ one, which is probably too old for that target.

Nikita Popov (May 20 2020 at 17:54, on Zulip):

I can apply this to our LLVM fork for now and open an issue for updating the freebsd toolchain. Though also happy to just disable the freebsd builds, if that's preferred.

Alex Crichton (May 20 2020 at 18:06, on Zulip):

@Nikita Popov nice! That seems like a fine patch to drop in

Alex Crichton (May 20 2020 at 18:06, on Zulip):

it's not even something we use

Alex Crichton (May 20 2020 at 18:06, on Zulip):

or, well maybe we do ship that nowadays

Alex Crichton (May 20 2020 at 18:06, on Zulip):

if that fixes the build, it's probably best to land that patch but also open an issue and cc freebsd folks

Alex Crichton (May 20 2020 at 18:07, on Zulip):

it seems harmless enough to carry for now but if we can fix the underlying problem that'd be best since this will likely crop up again

Nikita Popov (May 20 2020 at 18:30, on Zulip):

Yeah. Old distros versions used in CI are a recurring problem with LLVM upgrades. I've opened https://github.com/rust-lang/rust/issues/72390 but not sure who to ping for FreeBSD. Do you happen to know anyone offhand?

Alex Crichton (May 20 2020 at 19:18, on Zulip):

Ah sorry I don't know anyone offhand, I'd just git blame the toolchain script and cc the folks there

Alex Crichton (May 20 2020 at 19:18, on Zulip):

It should be possible to update the distros at any time, it just requires an explicit opt-in which requires some work

semarie (May 21 2020 at 07:01, on Zulip):

on FreeBSD side, I think that Alan Somers (@asomers on github) is still active on rust work. Else, he should be able to ping the right person.

Nikita Popov (May 23 2020 at 09:31, on Zulip):

Alex Crichton said:

Nikita Popov btw once this lands, mind gc'ing the old 10.0 branches which ended up getting unused?

There's one unused branch at https://github.com/rust-lang/llvm-project/tree/rustc/10.0-2020-02-05 (all the other ones were on my fork). I tried deleting it, but the repo uses branch protection, so it was rejected.

Alex Crichton (May 26 2020 at 14:16, on Zulip):

@Nikita Popov oh oops good point, should be deleted now!

Last update: Jul 02 2020 at 19:30UTC