Rollup of 5 pull requests #55230
Merged
Rollup of 5 pull requests #55230
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
The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion], and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to, again, try to fix this issue. The fundamental problem here remains the same, if a SIMD vector argument is passed by-value in LLVM's function type, then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value, but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We, just before codegen, will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working, and it unfortunately is likely producing suboptimal code, even in release mode. The saving grace for this, in theory, is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store, and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass, only doing the reverse. In local testing this... Closes rust-lang#50154 Closes rust-lang#52636 Closes rust-lang#54583 Closes rust-lang#55059 [quite a lot]: rust-lang#47743 [discussion]: rust-lang#44367 [wasn't]: rust-lang#50154
when you try to edit a crate inside the compiler tree using rls, it generates it's assets under target/rls, then tidy is trying to validate line lenghts for C headers, etc
|
@bors p=20 r+ |
|
📌 Commit b11933f08625140b4d8cd61f55b834bfd8f81b80 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit b11933f08625140b4d8cd61f55b834bfd8f81b80 with merge b313797f502a1b4e967cc8bcd5998253b2a3006b... |
|
💔 Test failed - status-appveyor |
bors
added
S-waiting-on-review
The issue of passing around SIMD types as values between functions has seen [quite a lot] of [discussion], and although we thought [we fixed it][quite a lot] it [wasn't]! This PR is a change to rustc to, again, try to fix this issue. The fundamental problem here remains the same, if a SIMD vector argument is passed by-value in LLVM's function type, then if the caller and callee disagree on target features a miscompile happens. We solve this by never passing SIMD vectors by-value, but LLVM will still thwart us with its argument promotion pass to promote by-ref SIMD arguments to by-val SIMD arguments. This commit is an attempt to thwart LLVM thwarting us. We, just before codegen, will take yet another look at the LLVM module and demote any by-value SIMD arguments we see. This is a very manual attempt by us to ensure the codegen for a module keeps working, and it unfortunately is likely producing suboptimal code, even in release mode. The saving grace for this, in theory, is that if SIMD types are passed by-value across a boundary in release mode it's pretty unlikely to be performance sensitive (as it's already doing a load/store, and otherwise perf-sensitive bits should be inlined). The implementation here is basically a big wad of C++. It was largely copied from LLVM's own argument promotion pass, only doing the reverse. In local testing this... Closes rust-lang#50154 Closes rust-lang#52636 Closes rust-lang#54583 Closes rust-lang#55059 [quite a lot]: rust-lang#47743 [discussion]: rust-lang#44367 [wasn't]: rust-lang#50154
…isdreavus Sending this PR in today so we can see what linkchecker wants overnight; please don't r+ until travis is green!
…akis Sometimes I just return `ty::List::empty()` because I cannot express these \"built-in\" clauses without bound tys support. r? @nikomatsakis
when you try to edit a crate inside the compiler tree using rls, it generates it's assets under target/rls, then tidy is trying to validate line lenghts for C headers, etc
|
@bors r+ |
|
📌 Commit f2848a0 has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Oct 20, 2018
Rollup of 5 pull requests Successful merges: - #55156 (Fixed: Multiple errors on single typo in match pattern) - #55189 (update books for the next release) - #55193 (make asm diagnostic instruction optional) - #55203 (Write an initial version of the `program_clauses` callback) - #55213 (ignore target folders) Failed merges: r? @ghost
|
☀️ Test successful - status-appveyor, status-travis |
Closed
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.
Successful merges:
program_clausescallback #55203 (Write an initial version of theprogram_clausescallback)Failed merges:
r? @ghost