summary refs log tree commit diff
path: root/src/librustc_codegen_llvm
AgeCommit message (Collapse)AuthorLines
2018-11-05Auto merge of #55593 - nikic:remove-llvm-4-checks, r=rkruppebors-32/+6
Remove checks for LLVM < 4.0 While we still have to support LLVM 4.0 for Emscripten, we can drop checks for LLVM >= 4.0 and < 4.0.
2018-11-04rustc_target: pass contexts by reference, not value.Eduard-Mihai Burtescu-9/+9
2018-11-04Support memcpy/memmove with differing src/dst alignmentNikita Popov-47/+60
If LLVM 7 is used, generate memcpy/memmove with differing src/dst alignment. I've added new FFI functions to construct these through the builder API, which is more convenient than dealing with differing intrinsic signatures depending on the LLVM version.
2018-11-04Auto merge of #55349 - bjorn3:rustc_mir_collect_and_partition_mono_items, ↵bors-1873/+20
r=oli-obk Move collect_and_partition_mono_items to rustc_mir Most of the logic of it is inside rustc_mir anyway. Also removes the single function crate rustc_metadata_utils. Based on #55225
2018-11-03Implement rotate using funnel shift on LLVM >= 7Nikita Popov-5/+45
Implement the rotate_left and rotate_right operations using llvm.fshl and llvm.fshr if they are available (LLVM >= 7). Originally I wanted to expose the funnel_shift_left and funnel_shift_right intrinsics and implement rotate_left and rotate_right on top of them. However, emulation of funnel shifts requires emitting a conditional to check for zero shift amount, which is not necessary for rotates. I was uncomfortable doing that here, as I don't want to rely on LLVM to optimize away that conditional (and for variable rotates, I'm not sure it can). We should revisit that question when we raise our minimum version requirement to LLVM 7 and don't need emulation code anymore.
2018-11-03Move collect_and_partition_mono_items to rustc_mirbjorn3-153/+6
2018-11-03Move cg_llvm::back::linker to cg_utilsbjorn3-1720/+14
2018-11-03Auto merge of #55330 - scalexm:bound-ty, r=nikomatsakisbors-3/+4
Add support for bound types This PR may have some slight performance impacts, I don't know how hot is the code I touched. Also, this breaks clippy and miri. r? @nikomatsakis
2018-11-03Rename `Binder::no_late_bound_regions` to `Binder::no_bound_vars`scalexm-1/+1
2018-11-03Shift both late bound regions and bound typesscalexm-2/+2
2018-11-03Move `BoundTy` to `ty::TyKind`scalexm-0/+1
2018-11-03Auto merge of #55238 - alexcrichton:rm-jemalloc, r=estebankbors-10/+104
Remove the `alloc_jemalloc` crate This commit removes the `alloc_jemalloc` crate from the standard library and all related configuration. We will no longer be shipping this unstable crate. Rationale for this is provided on https://github.com/rust-lang/rust/issues/36963 and the many linked issues, but I can inline rationale here if desired! We currently rely on jemalloc for increased perf in the Rust compiler, however. [This perf run shows](https://perf.rust-lang.org/compare.html?start=74ff7dcb1388e60a613cd6050bcd372a3cc4998b&end=7e7928dc0340d79b404e93f0c79eb4b946c1d669&stat=wall-time) that if we switch to glibc 2.23's allocator that it's slower than jemalloc across many benchmarks. [This perf run, however](https://perf.rust-lang.org/compare.html?start=22cc2ae8057d14e980b7c784e1eb2eee26b59e7d&end=10c95ccfa7a7adc12f4e608621ca29f9b98eed29), shows that if we use `jemalloc-sys` from crates.io then rustc actually gets faster across all benchmarks! (presumably because it has a more recent version of jemalloc than our submodule). As a result, it's expected that this doesn't regress any code (as it's just removing an unstable crate) and it should actually improve rustc performance because it updates jemalloc. Closes #36963
2018-11-03Auto merge of #54383 - mikeyhew:custom-receivers-object-safety, r=nikomatsakisbors-19/+79
Take 2: Implement object-safety and dynamic dispatch for arbitrary_self_types This replaces #50173. Over the months that that PR was open, we made a lot of changes to the way this was going to be implemented, and the long, meandering comment thread and commit history would have been confusing to people reading it in the future. So I decided to package everything up with new, straighforward commits and open a new PR. Here are the main points. Please read the commit messages for details. - To simplify codegen, we only support receivers that have the ABI of a pointer. That means they are builtin pointer types, or newtypes thereof. - We introduce a new trait: `DispatchFromDyn<T>`, similar to `CoerceUnsized<T>`. `DispatchFromDyn` has extra requirements that `CoerceUnsized` does not: when you implement `DispatchFromDyn` for a struct, there cannot be any extra fields besides the field being coerced and `PhantomData` fields. This ensures that the struct's ABI is the same as a pointer. - For a method's receiver (e.g. `self: Rc<Self>`) to be object-safe, it needs to have the following property: - let `DynReceiver` be the receiver when `Self = dyn Trait` - let `ConcreteReceiver` be the receiver when `Self = T`, where `T` is some unknown `Sized` type that implements `Trait`, and is the erased type of the trait object. - `ConcreteReceiver` must implement `DispatchFromDyn<DynReceiver>` In the case of `Rc<Self>`, this requires `Rc<T>: DispatchFromDyn<Rc<dyn Trait>>` These rules are explained more thoroughly in the doc comment on `receiver_is_dispatchable` in object_safety.rs. r? @nikomatsakis and @eddyb cc @arielb1 @cramertj @withoutboats Special thanks to @nikomatsakis for getting me un-stuck when implementing the object-safety checks, and @eddyb for helping with the codegen parts. EDIT 2018-11-01: updated because CoerceSized has been replaced with DispatchFromDyn
2018-11-02Auto merge of #55087 - levex:e0669-improve-span, r=nagisabors-8/+5
rustc: improve E0669 span E0669 refers to an operand that cannot be coerced into a single LLVM value, unfortunately right now this uses the Span for the entire inline assembly statement, which is less than ideal. This commit preserves the Span from HIR, which lets us emit the error using the Span for the operand itself in MIR. r? @nagisa cc/ @parched
2018-11-02rustc: Wait for all codegen threads to exitAlex Crichton-10/+104
This commit updates rustc to wait for all codegen threads to exit before allowing the main thread to exit. This is a stab in the dark to fix the mysterious segfaults appearing on #55238, and hopefully we'll see whether this actually fixes things in practice...
2018-11-02Auto merge of #55316 - RalfJung:retagging, r=oli-obkbors-2/+3
Add Retagging statements This adds a `Retag` statement kind to MIR, used to perform the retagging operation from [Stacked Borrows](https://www.ralfj.de/blog/2018/08/07/stacked-borrows.html). It also kills the old `Validate` statements that I added last year. NOTE: This includes https://github.com/rust-lang/rust/pull/55270. Only [these commits are new](https://github.com/RalfJung/rust/compare/stacked-borrows-ng...RalfJung:retagging).
2018-11-01Add comments explaining how codegen works for `dyn Trait` methodsMichael Hewson-2/+11
2018-11-01Implement object-safety for arbitrary_self_types: part 2Michael Hewson-19/+70
For now, all of the receivers that we care about are just a newtyped pointer — i.e. `Box<Self>`, `Rc<Self>`, `Pin<Box<Self>>`, `Pin<&mut Self>`. This is much simpler to implement in codeine than the more general case, because the ABI is the same as a pointer. So we add some checks in typeck/coherence/builtin.rs to make sure that implementors of CoerceSized are just newtyped pointers. In this commit, we also implement the codegen bits.
2018-11-01Remove checks for LLVM < 4.0Nikita Popov-32/+6
While we still have to support LLVM 4.0 for Emscripten, we can drop checks for LLVM >= 4.0 and < 4.0.
2018-10-30Avoid possible integer overflow in niche value computationTom Tromey-2/+5
@eddyb pointed out in review that the niche value computation had a possible integer overflow problem, fixed here as he suggested.
2018-10-30Address review commentsTom Tromey-11/+11
This fixes the issues pointed out in review.
2018-10-30Fix DWARF generation for enumsTom Tromey-145/+407
The DWARF generated for Rust enums was always somewhat unusual. Rather than using DWARF constructs directly, it would emit magic field names like "RUST$ENCODED$ENUM$0$Name" and "RUST$ENUM$DISR". Since PR #45225, though, even this has not worked -- the ad hoc scheme was not updated to handle the wider variety of niche-filling layout optimizations now available. This patch changes the generated DWARF to use the standard tags meant for this purpose; namely, DW_TAG_variant and DW_TAG_variant_part. The patch to implement this went in to LLVM 7. In order to work with older versions of LLVM, and because LLVM doesn't do anything here for PDB, the existing code is kept as a fallback mode. Support for this DWARF is in the Rust lldb and in gdb 8.2. Closes #32920 Closes #32924 Closes #52762 Closes #53153
2018-10-29Emit Retag statements, kill Validate statementsRalf Jung-2/+3
Also "rename" -Zmir-emit-validate to -Zmir-emit-retag, which is just a boolean (yes or no).
2018-10-28inline-asm: emit as many E0669 errors as we canLevente Kurusa-8/+5
Signed-off-by: Levente Kurusa <lkurusa@acm.org>
2018-10-27Auto merge of #54183 - qnighy:by-value-object-safety, r=oli-obkbors-90/+58
Implement by-value object safety This PR implements **by-value object safety**, which is part of unsized rvalues #48055. That means, with `#![feature(unsized_locals)]`, you can call a method `fn foo(self, ...)` on trait objects. One aim of this is to enable `Box<FnOnce>` in the near future. The difficulty here is this: when constructing a vtable for a trait `Foo`, we can't just put the function `<T as Foo>::foo` into the table. If `T` is no larger than `usize`, `self` is usually passed directly. However, as the caller of the vtable doesn't know the concrete `Self` type, we want a variant of `<T as Foo>::foo` where `self` is always passed by reference. Therefore, when the compiler encounters such a method to be generated as a vtable entry, it produces a newly introduced instance called `InstanceDef::VtableShim(def_id)` (that wraps the original instance). the shim just derefs the receiver and calls the original method. We give different symbol names for the shims by appending `::{{vtable-shim}}` to the symbol path (and also adding vtable-shimness as an ingredient to the symbol hash). r? @eddyb
2018-10-27Correct alignment of atomic types and (re)add Atomic{I,U}128Oliver Middleton-13/+10
LLVM requires that atomic loads and stores be aligned to at least the size of the type.
2018-10-27Refactor and add `PlaceContext::AscribeUserTy`.David Wood-17/+32
This commit refactors `PlaceContext` to split it into four different smaller enums based on if the context represents a mutating use, non-mutating use, maybe-mutating use or a non-use (this is based on the recommendation from @oli-obk on Zulip[1]). This commit then introduces a `PlaceContext::AscribeUserTy` variant. `StatementKind::AscribeUserTy` is now correctly mapped to `PlaceContext::AscribeUserTy` instead of `PlaceContext::Validate`. `PlaceContext::AscribeUserTy` can also now be correctly categorized as a non-use which fixes an issue with constant promotion in statics after a cast introduces a `AscribeUserTy` statement. [1]: https://rust-lang.zulipchat.com/#narrow/stream/122657-wg-nll/subject/.2355288.20cast.20fails.20to.20promote.20to.20'static/near/136536949
2018-10-26Add the actual chain of projections to `UserTypeProjection`.Felix S. Klock II-2/+5
Update the existing NLL `patterns.rs` test accordingly. includes changes addressing review feedback: * Added example to docs for `UserTypeProjections` illustrating how we build up multiple projections when descending into a pattern with type ascriptions. * Adapted niko's suggested docs for `UserTypeProjection`. * Factored out `projection_ty` from more general `projection_ty_core` (as a drive-by, made its callback an `FnMut`, as I discovered later that I need that). * Add note to docs that `PlaceTy.field_ty(..)` does not normalize its result. * Normalize as we project out `field_ty`.
2018-10-26Auto merge of #55382 - kennytm:rollup, r=kennytmbors-1/+1
Rollup of 21 pull requests Successful merges: - #54816 (Don't try to promote already promoted out temporaries) - #54824 (Cleanup rustdoc tests with `@!has` and `@!matches`) - #54921 (Add line numbers option to rustdoc) - #55167 (Add a "cheap" mode for `compute_missing_ctors`.) - #55258 (Fix Rustdoc ICE when checking blanket impls) - #55264 (Compile the libstd we distribute with -Ccodegen-unit=1) - #55271 (Unimplement ExactSizeIterator for MIR traversing iterators) - #55292 (Macro diagnostics tweaks) - #55298 (Point at macro definition when no rules expect token) - #55301 (List allowed tokens after macro fragments) - #55302 (Extend the impl_stable_hash_for! macro for miri.) - #55325 (Fix link to macros chapter) - #55343 (rustbuild: fix remap-debuginfo when building a release) - #55346 (Shrink `Statement`.) - #55358 (Remove redundant clone (2)) - #55370 (Update mailmap for estebank) - #55375 (Typo fixes in configure_cmake comments) - #55378 (rustbuild: use configured linker to build boostrap) - #55379 (validity: assert that unions are non-empty) - #55383 (Use `SmallVec` for the queue in `coerce_unsized`.) - #55391 (bootstrap: clean up a few clippy findings)
2018-10-26Auto merge of #53821 - oli-obk:sanity_query, r=RalfJungbors-17/+18
Report const eval error inside the query Functional changes: We no longer warn about bad constants embedded in unused types. This relied on being able to report just a warning, not a hard error on that case, which we cannot do any more now that error reporting is consistently centralized. r? @RalfJung fixes #53561
2018-10-26Remove redundant cloneShotaro Yamada-1/+1
2018-10-25Rebase fallout in ui outputOliver Schneider-2/+0
2018-10-25Report const eval error inside the queryOliver Schneider-16/+19
2018-10-24Move codegen_llvm::common::ty_fn_sig into rustc::ty::Instance.Masaki Hara-86/+11
2018-10-24Make declare_fn accept PolyFnSig instead of Ty.Masaki Hara-19/+17
2018-10-24Ensure virtual call receiver PassMode.Masaki Hara-0/+2
2018-10-24Implement by-value trait object method call.Masaki Hara-8/+14
2018-10-24Resolve to Instance::VtableShim when necessary.Masaki Hara-1/+17
2018-10-24Make declare_fn aware of vtable shims.Masaki Hara-6/+8
2018-10-24Add ty_fn_sig_vtable for getting adjusted signature for vtable shims.Masaki Hara-2/+21
2018-10-23fix typos in various placesMatthias Krüger-1/+1
2018-10-23Revert "rustc: Fix (again) simd vectors by-val in ABI"Alex Crichton-40/+8
This reverts commit 3cc8f738d4247a9b475d8e074b621e602ac2b7be.
2018-10-20Rollup merge of #55073 - alexcrichton:demote-simd, r=nagisaManish Goregaokar-8/+40
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 #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154
2018-10-20Auto merge of #55014 - ljedrz:lazyboye_unwraps, r=matthewjasperbors-4/+4
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`. An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
2018-10-19Prefer `Default::default` over `FxHash*::default` in struct constructorsOliver Scherer-42/+26
2018-10-19Deprecate the `FxHashMap()` and `FxHashSet()` constructor function hackOliver Scherer-28/+28
2018-10-19rustc: Fix (again) simd vectors by-val in ABIAlex Crichton-8/+40
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 #50154 Closes #52636 Closes #54583 Closes #55059 [quite a lot]: https://github.com/rust-lang/rust/pull/47743 [discussion]: https://github.com/rust-lang/rust/issues/44367 [wasn't]: https://github.com/rust-lang/rust/issues/50154
2018-10-19Prefer unwrap_or_else to unwrap_or in case of function calls/allocationsljedrz-4/+4
2018-10-18Rollup merge of #55128 - varkor:LLVMRustInlineAsmVerify-return-bool, r=rkruppekennytm-3/+3
Fix LLVMRustInlineAsmVerify return type mismatch Fixes https://github.com/rust-lang/rust/issues/54918. r? @rkruppe cc @levex
2018-10-18Rollup merge of #55016 - oli-obk:vtables💥_vtables_everywhere, r=RalfJungkennytm-0/+4
Deduplicate some code and compile-time values around vtables r? @RalfJung
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 07:30:45 +0000