Upgrade Emscripten targets to use upstream LLVM backend #63649
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
TODO: update CI to install and use upstream emscripten to run tests. The ui/statics/static-mut-foreign.rs test will not pass without rust-lang/libc#1478 and possibly a patch to wasm-ld. There are also some outstanding undiagnosed test failures on js-unknown-emscripten, so wasm2js will probably require more bugfixes before this can land as well. |
tlively
commented
Aug 17, 2019
| // wasm32 can't build the test helpers | ||
| if !target.contains("wasm32") { | ||
| builder.ensure(native::TestHelpers { target }); | ||
| } |
There was a problem hiding this comment.
I'm not sure which LLVM versions rust supports, so this may not be correct. This change was necessary to uncover all the ABI problems, though.
There was a problem hiding this comment.
FWIW this may fail on CI for the wasm32-unknown-unknown target, but I think that it'll probably work in that it'll generate a native library with ELF code (using clang) and then we'd just ignore it during the test suite. In that sense let's just ignore this for now and if it causes problems on CI we can add it back, but only for the non-emscripten target
There was a problem hiding this comment.
I believe this is the line that's failing on CI, this'll need to be disabled still for wasm32-unknown-unknown I believe
JohnTitor
added
the
S-waiting-on-review
|
Thanks for the PR @tlively! I think we may want to hold off on the target renaming yet, I suspect there's probably enough users of the target that this is already going to be somewhat breaking but changing names may be a bit aggressive for a first step. I definitely agree that the new naming is better, just thinking we may want to roll it out a bit slowly (also since it's just purely naming). The main thing I'm worried about is if anyone's using For CI, You can edit Would this be able to remove |
tlively
commented
Aug 19, 2019
hdhoang
added
S-waiting-on-author
|
ping from triage @tlively, any updates on this? |
|
Still on my radar! I've been mostly working on getting the CI to pass on the related PR rust-lang/libc#1478. I'm pretty sure that needs to be merged before this one, but I'm not sure how libc gets rolled into rustc. I will be updating this PR in response to the review comments next week. |
bjorn3
reviewed
Sep 1, 2019
|
|
||
| fn classify_ret_ty<Ty>(ret: &mut ArgType<'_, Ty>) { | ||
| ret.extend_integer_width_to(32); |
There was a problem hiding this comment.
Can you explain why? There’s no need to expand i8s and i16s to i32s during the lowering to LLVM IR because LLVM will perform the necessary type legalization itself. In fact, it’s better not to do the expansion here so that legalization is handled by the same system for both C/C++ and Rust.
There was a problem hiding this comment.
I agree with @bjorn3, Clang appears to do this: https://github.com/llvm/llvm-project/blob/d01b4a786271c9ce9df43add56ec2e3fb40ce920/clang/lib/CodeGen/TargetInfo.cpp#L716
| } | ||
|
|
||
| fn classify_arg_ty<Ty>(arg: &mut ArgType<'_, Ty>) { | ||
| arg.extend_integer_width_to(32); |
There was a problem hiding this comment.
I agree with @bjorn3, Clang appears to do this: https://github.com/llvm/llvm-project/blob/d01b4a786271c9ce9df43add56ec2e3fb40ce920/clang/lib/CodeGen/TargetInfo.cpp#L701
There was a problem hiding this comment.
Yeah, it's confusing that this happens in both the frontend and the backend. I suppose if we're trying to match clang here then it would make sense to do the expansion, although practically it shouldn't make a difference.
There was a problem hiding this comment.
I think the difference is we pick sign- or zero- extension depending on the type, which LLVM doesn't know, so presumably it would be correct for unsigned integers but not signed, or vice-versa.
I didn't really like this entire dance but IIRC @rkruppe explained at some point that it makes life easier for architectures with e.g. 32-bit registers that you want to do 16-bit or 8-bit operations within, if everything is appropriately extended with its individual signedness.
There was a problem hiding this comment.
Yeah that makes sense actually 👍
| @@ -377,6 +377,7 @@ | |||
| # but you can also optionally enable the "emscripten" backend for asm.js or | |||
| # make this an empty array (but that probably won't get too far in the | |||
| # bootstrap) | |||
| # FIXME: remove the obsolete emscripten backend option. | |||
There was a problem hiding this comment.
Please keep the codegen-backends option when you remove that.
|
☔ The latest upstream changes (presumably #64246) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Update: I've undone the asmjs => js renaming locally and everything is working well. I'm now experimenting with enabling Emscripten's exception handling to allow panic=unwind, but am running into some bug, probably in LLVM. If that takes much longer I will update this PR to use panic=abort and leave panic=unwind support for the future. |
|
Ah, of course the exception handling doesn't work because https://reviews.llvm.org/rG5c3cdef84b82464756bb571c13c31cf7773860c3 has not been merged into Rust's LLVM fork. I'll create a separate issue for that and update this PR to use panic=abort since I don't know how long that will take. |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
Oops, looks like I accidentally changed all the submodules 🙃 |
There was a problem hiding this comment.
Looks great to me!
Would you be ok editing src/ci/azure-pipelines/pr.yml to include the asmjs/wasm entries of src/ci/azure-pipelines/auto.yml temporarily? That would ensure that these builds all still pass on this PR, and then we can back that out just before merging with bors.
| # asmjs-specific backend assertion trip), so disable assertions for these | ||
| # tests. | ||
| ENV NO_LLVM_ASSERTIONS=1 | ||
| ENV NO_DEBUG_ASSERTIONS=1 |
There was a problem hiding this comment.
FWIW I think we trimmed down the tests run on the emscripten builder because of how long it took, so this may want to preserve the lack of assertions and running just a few test suites
There was a problem hiding this comment.
My hope is that with the upstream LLVM backend instead of Fastcomp the performance should be similar to that of other targets so we can give it the full testing treatment, but I'd be happy to put these limits back if that does not pan out.
|
|
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
I haven't done much analysis of the timing, but those did run for a bit of a long time. It looks like there's some asmjs failures, but perhaps we could switch back to running a subset of tests and then expand it later if necessary? We're already bleeding for time in a lot of areas so I don't think we can afford taking too much longer. Otherwise I'm realizing now that |
The The The other three test failures were in new tests that had |
New |
|
If tests require something like a newer |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
We believe the link failure is due to a recent emscripten regression, so this will have to wait for a bit before the libstd, libcore, or liballoc tests can be run. |
|
Is the only error here you're referencing the part about |
|
Interestingly rpath passing is already turned off for the emscripten target, and yet an rpath argument is still being passed. The regression with emscripten is that we used to ignore rpath arguments but now we erroneously pass them through. So we can either wait for that to be fixed or figure out why an rpath is being passed in the first place. I will dive in deeper once I finish some of the other stuff I'm doing. |
tlively
added a commit
to tlively/rust
that referenced
this pull request
Oct 8, 2019
Updates LLVM to pick up the cherry-picked support for correctly handling exception handling with aggregates passed by value. This will be necessary to continue to support Emscripten's exception handling once we switch using Emscripten's LLVM backend. See rust-lang#63649.
Centril
added a commit
to Centril/rust
that referenced
this pull request
Oct 9, 2019
…exceptions, r=nikic Update LLVM for Emscripten exception handling support Updates LLVM to pick up the cherry-picked support for correctly handling exception handling with aggregates passed by value. This will be necessary to continue to support Emscripten's exception handling once we switch using Emscripten's LLVM backend. See rust-lang#63649.
tmandry
added a commit
to tmandry/rust
that referenced
this pull request
Oct 11, 2019
…exceptions, r=nikic Update LLVM for Emscripten exception handling support Updates LLVM to pick up the cherry-picked support for correctly handling exception handling with aggregates passed by value. This will be necessary to continue to support Emscripten's exception handling once we switch using Emscripten's LLVM backend. See rust-lang#63649.
tlively
added a commit
to tlively/rust
that referenced
this pull request
Oct 17, 2019
- Compatible with Emscripten 1.38.46-upstream or later upstream. - Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the old incorrect wasm32 C call ABI with the correct one, preserving the old one as wasm32_bindgen_compat for wasm-bindgen compatibility. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Uses EMCC_CFLAGS on CI to avoid the timeout problems with rust-lang#63649.
bors
added a commit
that referenced
this pull request
Oct 17, 2019
Upgrade Emscripten targets to use upstream LLVM backend - Compatible with Emscripten 1.38.46-upstream or later upstream. - Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the old incorrect wasm32 C call ABI with the correct one, preserving the old one as wasm32_bindgen_compat for wasm-bindgen compatibility. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649. r? @alexcrichton
ehuss
added a commit
to ehuss/rust-forge
that referenced
this pull request
May 15, 2020
wasm32-experimental-emscripten was removed in rust-lang/rust#63649 (or rust-lang/rust#65251).
bjorn3
added a commit
to bjorn3/rust
that referenced
this pull request
Jul 16, 2020
This is no longer used since rust-lang#63649
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 17, 2020
…r=spastorino Remove leftover from emscripten fastcomp support This is no longer used since rust-lang#63649
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Jul 17, 2020
…r=spastorino Remove leftover from emscripten fastcomp support This is no longer used since rust-lang#63649
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
targets.
version, which is correct for both wasm32 and JS.
because supporting unwinding will require an LLVM patch.