Upgrade to LLVM's 3.7 release branch #27076
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
|
r? @pcwalton (rust_highfive has picked a reviewer for you, use r? to override) |
|
r? @brson |
|
@bors r+ |
|
📌 Commit 181661f has been approved by |
|
🎊 |
|
@bors: r-, turns out there's still bugs on OSX and Windows, taking some time to fix those up. So far:
And probably one or two more on the way! |
There's a number of goodies in this LLVM update: * This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957 which should help us bootstrap farther on 32-bit MSVC targets. * There is better support for writing multiple flavors of archives, allowing us to use the built-in LLVM support instead of the system `ar` on all current platforms of the compiler. * A number of other minor bug fixes and performance improvements to unblock various other pieces of work.
This is for llvm/cc714e214298cfbf11de65b46de31900d51422cf
The C API of this function changed so it no longer takes a personality function. A shim was introduced to call the right LLVM function (depending on which version we're compiled against) to set the personality function on the outer function. The compiler only ever sets one personality function for all generated functions, so this should be equivalent.
Updates our LLVM bindings to be able to write out multiple kinds of archives. This commit also enables using LLVM instead of the system ar on all current targets.
Turns out for OSX our data layout was subtly wrong and the LLVM update must have exposed this. Instead of fixing this I've removed all data layouts from the compiler to just use the defaults that LLVM provides for all targets. All data layouts (and a number of dead modules) are removed from the compiler here. Custom target specifications can still provide a custom data layout, but it is now an optional key as the default will be used if one isn't specified.
alexcrichton
force-pushed
the
update-llvm
branch
from
181661f to
958d563
Compare
|
@bors force |
|
⌛ Testing commit 958d563 with merge 71fea82... |
|
💔 Test failed - auto-mac-32-opt |
|
Depends on #27070 |
Re-enabling it is tracked in rust-lang#27089
|
@bors: p=1 |
bors
added a commit
that referenced
this pull request
Jul 17, 2015
LLVM has recently created their 3.7 release branch, and this PR updates us to that point. This should hopefully mean that we're basically compatible with the upcoming 3.7 release. Additionally, there are a number of goodies on this branch. * This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957 which should help us bootstrap farther on 32-bit MSVC targets. * There is better support for writing multiple flavors of archives, allowing us to use the built-in LLVM support instead of the system `ar` on all current platforms of the compiler. * This LLVM has SafeStack support * An [optimization patch](rust-lang/llvm@7cf5e26) by @pcwalton is included. * A number of other minor test fixes here and there. Due to problems dealing with the data layout we pass to LLVM, this PR also takes the time to clean up how we specific this. We no longer specify a data layout to LLVM by default and instead take the default for the target from LLVM to pass to the module that we're building. This should be more robust going into the future, and I'm also not sure we know what any of these arcane strings are any more...
|
\o/ Thanks for getting us onto a new llvm (I can finally play with safestacks!) and keeping my tiny commit intact ❤️ |
dotdash
added a commit
to dotdash/rust
that referenced
this pull request
Jul 20, 2015
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076. Closes rust-lang#26468
Merged
steveklabnik
added a commit
to steveklabnik/rust
that referenced
this pull request
Jul 21, 2015
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076. Closes rust-lang#26468
steveklabnik
added a commit
to steveklabnik/rust
that referenced
this pull request
Jul 21, 2015
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076. Closes rust-lang#26468
steveklabnik
added a commit
to steveklabnik/rust
that referenced
this pull request
Jul 21, 2015
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076. Closes rust-lang#26468
steveklabnik
added a commit
to steveklabnik/rust
that referenced
this pull request
Jul 22, 2015
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076. Closes rust-lang#26468
steveklabnik
added a commit
to steveklabnik/rust
that referenced
this pull request
Jul 22, 2015
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076. Closes rust-lang#26468
steveklabnik
added a commit
to steveklabnik/rust
that referenced
this pull request
Jul 22, 2015
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076. Closes rust-lang#26468
steveklabnik
added a commit
to steveklabnik/rust
that referenced
this pull request
Jul 22, 2015
The fix for rust-lang#26468 was made upstream and landed with the LLVM update in rust-lang#27076. Closes rust-lang#26468
bors
added a commit
that referenced
this pull request
Apr 20, 2016
Compute LLVM-agnostic type layouts in rustc. Layout for monomorphic types, and some polymorphic ones (e.g. `&T` where `T: Sized`), can now be computed by rustc without involving LLVM in the actual process. This gives rustc the ability to evaluate `size_of` or `align_of`, as well as obtain field offsets. MIR-based CTFE will eventually make use of these layouts, as will MIR trans, shortly. Layout computation also comes with a `[breaking-change]`, or two: * `"data-layout"` is now mandatory in custom target specifications, reverting the decision from #27076. This string is needed because it describes endianness, pointer size and alignments for various types. We have the first two and we could allow tweaking alignments in target specifications. Or we could also extract the data layout from LLVM and feed it back into rustc. However, that can vary with the LLVM version, which is fragile and undermines stability. For built-in targets, I've added a check that the hardcoded data-layout matches LLVM defaults. * `transmute` calls are checked in a stricter fashion, which fixes #32377 To expand on `transmute`, there are only 2 allowed patterns: between types with statically known sizes and between pointers with the same potentially-unsized "tail" (which determines the type of unsized metadata they use, if any). If you're affected, my suggestions are: * try to use casts (and raw pointer deref) instead of transmutes * *really* try to avoid `transmute` where possible * if you have a structure, try working on individual fields and unpack/repack the structure instead of transmuting it whole, e.g. `transmute::<RefCell<Box<T>>, RefCell<*mut T>>(x)` doesn't work, but `RefCell::new(Box::into_raw(x.into_inner()))` does (and `Box::into_raw` is just a `transmute`)
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.
LLVM has recently created their 3.7 release branch, and this PR updates us to that point. This should hopefully mean that we're basically compatible with the upcoming 3.7 release. Additionally, there are a number of goodies on this branch.
which should help us bootstrap farther on 32-bit MSVC targets.
to use the built-in LLVM support instead of the system
aron all currentplatforms of the compiler.
Due to problems dealing with the data layout we pass to LLVM, this PR also takes the time to clean up how we specific this. We no longer specify a data layout to LLVM by default and instead take the default for the target from LLVM to pass to the module that we're building. This should be more robust going into the future, and I'm also not sure we know what any of these arcane strings are any more...