LLVM 5.0 Tracking Issue #43370

TimNN · 2017-07-20T20:02:47Z

The time has come again, LLVM is releasing 5.0 soon and Rust wants to / needs to follow.

I have started work on the upgrade in these branches:

rust-lang/rust: https://github.com/alexcrichton/rust/tree/llvm50
rust-lang/llvm: https://github.com/rust-lang/llvm/tree/rust-llvm-2017-07-20
rust-lang/compiler-rt: https://github.com/rust-lang/compiler-rt/tree/rust-2017-07-20
rust-lang-nursery/compiler-builtins: https://github.com/rust-lang-nursery/compiler-builtins/tree/llvm50

Open tasks

get asm.js working again - reenable JSBackend as a target
- add asm.js target to our fork - rust-lang/llvm@c9a2123
- update emscripten to LLVM 5.0

Completed tasks

Next steps:

Get rustllvm to compile (error log)

Current issues:

All but the first issues seem straight forward to fix, so I'll try to send PRs for those soon.

The text was updated successfully, but these errors were encountered:

TimNN · 2017-07-20T20:18:03Z

cc @nagisa, @michaelwoerister, @arielb1, @eddyb: You have been recommend as familiar with the rust llvm wrapper, would one of you mind looking into the attributes changes?

alexcrichton · 2017-07-21T20:11:30Z

With #43387 looks like rustc can bootstrap on x86_64-unknown-linux-gnu, but there's a lot of test failures. A full stage2 test run has tons of errors, lots of compiler segfaults. A stage1 test run has much fewer errors:

test [compile-fail] compile-fail/proc-macro/derive-bad.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/expand-to-unstable-2.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/expand-to-unstable.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/issue-38586.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/item-error.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/lints_in_proc_macros.rs ... FAILED
test [compile-fail] compile-fail/proc-macro/proc-macro-attributes.rs ... FAILED
test [codegen] codegen/lifetime_start_end.rs ... FAILED
test [codegen] codegen/issue-37945.rs ... FAILED
test [debuginfo-gdb] debuginfo-gdb/var-captured-in-nested-closure.rs ... FAILED
test [debuginfo-gdb] debuginfo-gdb/var-captured-in-sendable-closure.rs ... FAILED
test [debuginfo-gdb] debuginfo-gdb/var-captured-in-stack-closure.rs ... FAILED
test [run-make] run-make/llvm-pass ... FAILED
test [run-make] run-make/rustc-macro-dep-files ... FAILED
test [run-make] run-make/simd-ffi ... FAILED
test [run-pass] run-pass/debuginfo-lto.rs ... FAILED
test [run-pass] run-pass/issue-34569.rs ... FAILED
test [run-pass] run-pass/backtrace.rs ... FAILED
test [run-pass] run-pass/backtrace-debuginfo.rs ... FAILED
test [run-pass] run-pass/proc-macro/add-impl.rs ... FAILED
test [run-pass] run-pass/proc-macro/append-impl.rs ... FAILED
test [run-pass] run-pass/proc-macro/attr-args.rs ... FAILED
test [run-pass] run-pass/proc-macro/bang-macro.rs ... FAILED
test [run-pass] run-pass/proc-macro/count_compound_ops.rs ... FAILED
test [run-pass] run-pass/proc-macro/crate-var.rs ... FAILED
test [run-pass] run-pass/proc-macro/derive-same-struct.rs ... FAILED
test [run-pass] run-pass/proc-macro/issue-40001.rs ... FAILED
test [run-pass] run-pass/proc-macro/issue-39889.rs ... FAILED
test [run-pass] run-pass/proc-macro/hygiene_example.rs ... FAILED
test [run-pass] run-pass/proc-macro/use-reexport.rs ... FAILED
test [run-pass] run-pass/proc-macro/load-two.rs ... FAILED
test [run-pass] run-pass/issue-40663.rs ... FAILED

alexcrichton · 2017-07-21T20:42:00Z

@eddyb indicated on IRC that this function call may be responsible for the debuginfo-gdb failures, and he was spot on!

alexcrichton · 2017-07-21T20:58:25Z

I've filed https://bugs.llvm.org/show_bug.cgi?id=33883 related to the run-make/simd-ffi failure

eddyb · 2017-07-21T20:58:56Z

So LLVM got even worse (the current implementation sometimes creates an alloca to avoid pretty much this kind of misoptimization ruining complex llvm.dbg.declare).

The proper solution here at this point is to produce a pointer to every single closure capture (which means loading the respective pointer from the environment, if the capture is already by-ref), and then use llvm.dbg.value to indicate that... oh, wait, that won't work, let me step back.

Using llvm.dbg.declare once means that even if the value is modified later, a debugger knows where to get the value during the scope the name is defined for.
OTOH, llvm.dbg.value gives the value at that time, and even if you say the value is behind a pointer, that won't let the debugger see updated values from later writes to the same location.

Which means we need one alloca for every single capture (holding the pointers mentioned above). This is because of idiosyncratic LLVM limitations - even though there is a system for indicating multiple pointer offsets and dereferences to get from the argument to llvm.dbg.declare (or llvm.dbg.value) (a subset of "DWARF expressions"), and there's enough information to start from an arbitrary pointer on stack or in a register (for llvm.dbg.value), analloca is still required.

But with one llvm.dbg.declare per alloca, they should be simple enough not to break.

alexcrichton · 2017-07-21T21:06:21Z

The codegen/issue-37945.rs failure looks related to rust-lang/llvm#90. @arielb1 would you be able to help out diagnosing this one? I've verified that the llvm branch we have for 5.0 does indeed include those commits:

Do you think that this may have regressed in upstream LLVM?

alexcrichton · 2017-07-21T21:16:14Z

I think I fixed codegen/lifetime_start_end.rs in 38e40ce

TimNN · 2017-07-22T16:56:12Z

Edit: Nevermind this comment, those tests are expected to fail on stage 1.

Original comment

For a stage 1 test run, I get the same failures as @alexcrichton, for compile-fail proc macro derive:

thread '<unnamed>' panicked at 'proc_macro::__internal::with_sess() called before set_parse_sess()!', /home/logic/build-tmp/rust-src/src/libproc_macro/lib.rs:678:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.
fatal runtime error: failed to initiate panic, error 5

full logs

I'm not sure about the initial panic message, but the "failed to initiate panic" seems kind of bad (error 5 is apparently _URC_END_OF_STACK)

For run-pass proc-macro-derive:

index out of bounds: the len is 0 but the index is 4294967206

That also seems bad.

alexcrichton · 2017-07-22T17:00:00Z

@TimNN oh no need to worry about those, that's a benign failure. Procedural macros don't work in stage1 and not all tests are flagged as // ignore-stage1

Update Rust LLVM bindings for LLVM 5.0 This is the initial set of changes to update the rust llvm bindings for 5.0. The llvm commits necessitating these changes are linked from the tracking issue, #43370.

alexcrichton · 2017-07-24T22:55:48Z

Filed an upstream bug for the segfaults in rustc I've been seeing. (segfaults were happening on all platforms)

arielb1 · 2017-07-24T23:18:51Z

The codegen/issue-37945.rs failure looks related to rust-lang/llvm#90. @arielb1 would you be able to help out diagnosing this one? I've verified that the llvm branch we have for 5.0 does indeed include those commits:

Sure. That's probably https://bugs.llvm.org/show_bug.cgi?id=33470

alexcrichton · 2017-07-24T23:20:16Z

Ok thanks @arielb1! Do you think it'd be safe to ignore that test during the LLVM upgrade in favor of that upstream bug? Or do you think we should block the upgrade on fixing that?

arielb1 · 2017-07-24T23:26:12Z

The bug looks quite bad. Let's ignore it for now to see all the other bugs. I bet I can get it fixed first.

More info at rust-lang#43370 (comment)

alexcrichton · 2017-07-25T22:47:32Z

This tree of commits passes ./x.py test on x86_64-unknown-linux-gnu with LLVM assertions enabled.

alexcrichton · 2017-07-26T16:52:39Z

I've done a full travis run against a tree with a number of workarounds, and I believe all open issues are listed under "Open Tasks" above.

alexcrichton · 2017-07-30T04:25:02Z

@eddyb commenting out the call site you indicated fixes the debuginfo related asserts in LLVM, but it doesn't actually cause any tests in Rust to fail. Do you know of an example of a test that would fail if we don't emit that debuginfo?

eddyb · 2017-07-30T05:12:10Z

@alexcrichton Erm, that means we don't have tests for closures... without that call no closure captures can be seen from a debugger as a local variable (from within the closure body).
cc @michaelwoerister

rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening, but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The [current set of custom rustc-specific patches](rust-lang/llvm@f128612...rust-llvm-release-6-0-0) included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed, notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch, but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container, I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch), but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies, but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome, along with scrutiny of the "missing patches" like a [change to pass manager order](rust-lang/llvm@2717444), [another change to pass manager order](rust-lang/llvm@c782feb), some [compile fixes for sparc](rust-lang/llvm@1a83de6), and some [fixes for solaris](rust-lang/llvm@c2bfe0a). [patches4]: rust-lang/llvm@5401fdf...rust-llvm-release-4-0-1 [backport]: rust-lang/llvm@5c54c25 [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons, notably: * This'll allow us to keep up with the upstream wasm backend, picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors, especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend, but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction, but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang/stdarch#157 Closes rust-lang-nursery/rust-wasm#3

The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening, but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed, notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch, but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container, I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch), but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies, but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome, along with scrutiny of the "missing patches" like a [change to pass manager order](rust-lang/llvm@27174447533), [another change to pass manager order](rust-lang/llvm@c782febb7b9), some [compile fixes for sparc](rust-lang/llvm@1a83de63c42), and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: rust-lang/llvm@5401fdf...rust-llvm-release-4-0-1 [backport]: rust-lang/llvm@5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons, notably: * This'll allow us to keep up with the upstream wasm backend, picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors, especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend, but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction, but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang/stdarch#157 Closes rust-lang-nursery/rust-wasm#3

The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening, but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed, notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch, but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container, I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch), but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies, but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome, along with scrutiny of the "missing patches" like a [change to pass manager order](rust-lang/llvm@27174447533), [another change to pass manager order](rust-lang/llvm@c782febb7b9), some [compile fixes for sparc](rust-lang/llvm@1a83de63c42), and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: rust-lang/llvm@5401fdf...rust-llvm-release-4-0-1 [backport]: rust-lang/llvm@5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons, notably: * This'll allow us to keep up with the upstream wasm backend, picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors, especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by rust-lang#47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend, but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction, but we're not sure when that will happen! Closes rust-lang#43370 Closes rust-lang#43418 Closes rust-lang#47015 Closes rust-lang#47683 Closes rust-lang/stdarch#157 Closes rust-lang-nursery/rust-wasm#3

rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening, but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The [current set of custom rustc-specific patches](rust-lang/llvm@f128612...rust-llvm-release-6-0-0) included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed, notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch, but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container, I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch), but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies, but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome, along with scrutiny of the "missing patches" like a [change to pass manager order](rust-lang/llvm@2717444), [another change to pass manager order](rust-lang/llvm@c782feb), some [compile fixes for sparc](rust-lang/llvm@1a83de6), and some [fixes for solaris](rust-lang/llvm@c2bfe0a). [patches4]: rust-lang/llvm@5401fdf...rust-llvm-release-4-0-1 [backport]: rust-lang/llvm@5c54c25 [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons, notably: * This'll allow us to keep up with the upstream wasm backend, picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors, especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend, but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction, but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang/stdarch#157 Closes rust-lang-nursery/rust-wasm#3

The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening, but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The current set of custom rustc-specific patches included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed, notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch, but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container, I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch), but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies, but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome, along with scrutiny of the "missing patches" like a [change to pass manager order](rust-lang/llvm@27174447533), [another change to pass manager order](rust-lang/llvm@c782febb7b9), some [compile fixes for sparc](rust-lang/llvm@1a83de63c42), and some [fixes for solaris](rust-lang/llvm@c2bfe0abb). [patches4]: rust-lang/llvm@5401fdf...rust-llvm-release-4-0-1 [backport]: rust-lang/llvm@5c54c252db [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons, notably: * This'll allow us to keep up with the upstream wasm backend, picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors, especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by rust-lang#47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend, but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction, but we're not sure when that will happen! Closes rust-lang#43370 Closes rust-lang#43418 Closes rust-lang#47015 Closes rust-lang#47683 Closes rust-lang/stdarch#157 Closes rust-lang-nursery/rust-wasm#3

rustc: Upgrade to LLVM 6 The following submodules have been updated for a new version of LLVM: - `src/llvm` - `src/libcompiler_builtins` - transitively contains compiler-rt - `src/dlmalloc` This also updates the docker container for dist-i686-freebsd as the old 16.04 container is no longer capable of building LLVM. The compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without much interesting happening, but the LLVM update here is of particular note. Unlike previous updates I haven't cherry-picked all existing patches we had on top of our LLVM branch as we have a [huge amount][patches4] and have at this point forgotten what most of them are for. Instead I started from the current `release_60` branch in LLVM and only applied patches that were necessary to get our tests working and building. The [current set of custom rustc-specific patches](rust-lang/llvm@f128612...rust-llvm-release-6-0-0) included in this LLVM update are: * rust-lang/llvm@1187443 - this is how we actually implement `cfg(target_feature)` for now and continues to not be upstreamed. While a hazard for SIMD stabilization this commit is otherwise keeping the status quo of a small rustc-specific feature. * rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't upstreamed, notably teaching LLVM about our allocation-related routines (which aren't malloc/free). Once we stabilize the global allocator routines we will likely want to upstream this patch, but for now it seems reasonable to keep it on our fork. * rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in our 32-bit linux container. I'm not really sure why it's necessary but my guess is that it's because of the absolutely ancient glibc that we're using. In any case it's only updating pieces we're not actually using in LLVM so I'm hoping it'll turn out alright. This doesn't seem like something we'll want to upstream.c * rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our i686-freebsd container, I'm not really sure what's going on but we for sure probably don't want to upstream this and otherwise it seems not too bad for now at least. * rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug] which although diagnosed to a particular revision isn't currently fixed upstream (and the bug itself doesn't seem too active). This commit is a partial revert of the suspected cause of this regression (found via a bisection). I'm sort of hoping that this eventually gets fixed upstream with a similar fix (which we can replace in our branch), but for now I'm also hoping it's a relatively harmless change to have. After applying these patches (plus one [backport] which should be [backported upstream][llvm-back]) I believe we should have all tests working on all platforms in our current test suite. I'm like 99% sure that we'll need some more backports as issues are reported for LLVM 6 when this propagates through nightlies, but that's sort of just par for the course nowadays! In any case though some extra scrutiny of the patches here would definitely be welcome, along with scrutiny of the "missing patches" like a [change to pass manager order](rust-lang/llvm@2717444), [another change to pass manager order](rust-lang/llvm@c782feb), some [compile fixes for sparc](rust-lang/llvm@1a83de6), and some [fixes for solaris](rust-lang/llvm@c2bfe0a). [patches4]: rust-lang/llvm@5401fdf...rust-llvm-release-4-0-1 [backport]: rust-lang/llvm@5c54c25 [llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114 [upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096 --- The update to LLVM 6 is desirable for a number of reasons, notably: * This'll allow us to keep up with the upstream wasm backend, picking up new features as they start landing. * Upstream LLVM has fixed a number of SIMD-related compilation errors, especially around AVX-512 and such. * There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed in the LLVM 4 branch we're using. * Overall it's not a great idea to stagnate with our codegen backend! This update is mostly powered by #47730 which is allowing us to update LLVM *independent* of the version of LLVM that Emscripten is locked to. This means that when compiling code for Emscripten we'll still be using the old LLVM 4 backend, but when compiling code for any other target we'll be using the new LLVM 6 target. Once Emscripten updates we may no longer need this distinction, but we're not sure when that will happen! Closes #43370 Closes #43418 Closes #47015 Closes #47683 Closes rust-lang/stdarch#157 Closes rust-lang-nursery/rust-wasm#3

devurandom · 2018-03-10T10:06:39Z

This will first appear in Rust 1.25, correct?

cuviper · 2018-03-10T15:53:36Z

It will actually be LLVM 6, but yes, starting in 1.25.

The update to 1.24.0 in 4b2c24c erroneously switched to LLVM 5.0, which is still not supported by this rust version. Compiling with rustc will produce "invalid expression" messages. See: rust-lang/rust#43370 See: rust-lang/rust#47464

gaming-hacker · 2018-04-07T00:47:54Z

What's the status on implementing fixes for llvm-6.0?

martell · 2018-04-07T01:18:23Z

@gaming-hacker llvm 6.0 support was already shipped in 1.25.

gaming-hacker · 2018-04-14T19:32:15Z

@martell, thanks my bad. there was a nagging bug in Macports i was trying to nail down.

TimNN mentioned this issue Jul 21, 2017

Update Rust LLVM bindings for LLVM 5.0 #43387

Merged

TimNN self-assigned this Jul 21, 2017

Mark-Simulacrum added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Jul 23, 2017

alexcrichton added a commit to alexcrichton/rust that referenced this issue Jul 25, 2017

TMP: Ignore a declare_local in mir trans

8e0f883

More info at rust-lang#43370 (comment)

alexcrichton mentioned this issue Jul 30, 2017

LLVM 5.0 upgrade emscripten-core/emscripten-fastcomp#193

Closed

bors closed this as completed in #47828 Feb 10, 2018

raimue mentioned this issue Mar 27, 2018

rust: Downgrade to llvm-4.0 macports/macports-ports#1487

Merged

10 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LLVM 5.0 Tracking Issue #43370

LLVM 5.0 Tracking Issue #43370

TimNN commented Jul 20, 2017 •

edited by BatmanAoD

Loading

TimNN commented Jul 20, 2017

alexcrichton commented Jul 21, 2017

alexcrichton commented Jul 21, 2017

alexcrichton commented Jul 21, 2017

eddyb commented Jul 21, 2017 •

edited

Loading

alexcrichton commented Jul 21, 2017 •

edited

Loading

alexcrichton commented Jul 21, 2017

TimNN commented Jul 22, 2017 •

edited

Loading

alexcrichton commented Jul 22, 2017

alexcrichton commented Jul 24, 2017

arielb1 commented Jul 24, 2017

alexcrichton commented Jul 24, 2017

arielb1 commented Jul 24, 2017

alexcrichton commented Jul 25, 2017

alexcrichton commented Jul 26, 2017

alexcrichton commented Jul 30, 2017

eddyb commented Jul 30, 2017

devurandom commented Mar 10, 2018

cuviper commented Mar 10, 2018

gaming-hacker commented Apr 7, 2018

martell commented Apr 7, 2018

gaming-hacker commented Apr 14, 2018 •

edited

Loading

LLVM 5.0 Tracking Issue #43370

LLVM 5.0 Tracking Issue #43370

Comments

TimNN commented Jul 20, 2017 • edited by BatmanAoD Loading

Open tasks

Completed tasks

TimNN commented Jul 20, 2017

alexcrichton commented Jul 21, 2017

alexcrichton commented Jul 21, 2017

alexcrichton commented Jul 21, 2017

eddyb commented Jul 21, 2017 • edited Loading

alexcrichton commented Jul 21, 2017 • edited Loading

alexcrichton commented Jul 21, 2017

TimNN commented Jul 22, 2017 • edited Loading

alexcrichton commented Jul 22, 2017

alexcrichton commented Jul 24, 2017

arielb1 commented Jul 24, 2017

alexcrichton commented Jul 24, 2017

arielb1 commented Jul 24, 2017

alexcrichton commented Jul 25, 2017

alexcrichton commented Jul 26, 2017

alexcrichton commented Jul 30, 2017

eddyb commented Jul 30, 2017

devurandom commented Mar 10, 2018

cuviper commented Mar 10, 2018

gaming-hacker commented Apr 7, 2018

martell commented Apr 7, 2018

gaming-hacker commented Apr 14, 2018 • edited Loading

TimNN commented Jul 20, 2017 •

edited by BatmanAoD

Loading

eddyb commented Jul 21, 2017 •

edited

Loading

alexcrichton commented Jul 21, 2017 •

edited

Loading

TimNN commented Jul 22, 2017 •

edited

Loading

gaming-hacker commented Apr 14, 2018 •

edited

Loading