about summary refs log tree commit diff
path: root/src/librustc_codegen_llvm/back
AgeCommit message (Collapse)AuthorLines
2018-11-16[eddyb] rustc_codegen_ssa: avoid a `Clone` bound on `TargetMachine`.Eduard-Mihai Burtescu-1/+1
2018-11-16Separating the back folder between backend-agnostic and LLVM-specific codeDenis Merigoux-2277/+220
2018-11-16Finished moving backend-agnostic code to rustc_codegen_ssaDenis Merigoux-3/+3
2018-11-16Beginning of moving all backend-agnostic code to rustc_codegen_ssaDenis Merigoux-2/+2
2018-11-16Moved Backend interface into rustc_codegen_utilsDenis Merigoux-3/+4
2018-11-16Generalized base:codegen_crateDenis Merigoux-19/+18
2018-11-16Fixed typosDenis Merigoux-1/+1
2018-11-16Removed phantomdata no longer necessaryDenis Merigoux-13/+6
Because CodegenContext doesn't implement Backend anymore
2018-11-16Removing LLVM content from CommonMethods -> ConstMethodsDenis Merigoux-24/+5
2018-11-16Prefixed type methods & removed trait impl for write::CodegenContextDenis Merigoux-22/+3
2018-11-16Prefixed const methods with "const" instead of "c"Denis Merigoux-6/+6
2018-11-16Traitification of type_ methodsDenis Merigoux-1/+9
The methods are now attached to CodegenCx instead of Type
2018-11-16Added definition of type traitDenis Merigoux-0/+1
2018-11-16Removed code duplication for CommonWriteMethodsDenis Merigoux-13/+5
2018-11-16CommonWriteMethods are not static any moreDenis Merigoux-12/+56
2018-11-16Split CommonMethods to accomodate for use in back/write.rsDenis Merigoux-1/+1
2018-11-16Traitification of common.rs methodsDenis Merigoux-7/+7
2018-11-16Removed genericity over Value in various functionsDenis Merigoux-2/+1
Prelude to using associated types in traits rather than type parameters
2018-11-16Generalized base.rs#call_memcpy and everything that it usesDenis Merigoux-1/+2
Generalized operand.rs#nontemporal_store and fixed tidy issues Generalized operand.rs#nontemporal_store's implem even more With a BuilderMethod trait implemented by Builder for LLVM Cleaned builder.rs : no more code duplication, no more ValueTrait Full traitification of builder.rs
2018-11-11Auto merge of #55698 - nikic:remove-llvm-4-support, r=alexcrichtonbors-3/+1
Remove support for building against LLVM 4 With emscripten removed in #55626, we no longer need to support building against LLVM 4.
2018-11-10codegen_llvm_back: simplify a conversion to charljedrz-1/+1
2018-11-10codegen_llvm_back: remove a redundant continueljedrz-1/+0
2018-11-10codegen_llvm_back: possible minor speedup in logicljedrz-1/+1
2018-11-10codegen_llvm_back: remove 'static from constsljedrz-3/+3
2018-11-10codegen_llvm_back: use to_owned instead of to_string with string literalsljedrz-4/+4
2018-11-10codegen_llvm_back: improve common patternsljedrz-46/+23
2018-11-10codegen_llvm_back: remove explicit returnsljedrz-12/+15
2018-11-10codegen_llvm_back: use Cow<'static, str> where applicableljedrz-22/+21
2018-11-10codegen_llvm_back: whitespace & formatting fixesljedrz-50/+43
2018-11-06Run name-anon-globals after LTO passes as wellNikita Popov-2/+13
If we're going to emit bitcode (through ThinLTOBuffer), then we need to ensure that anon globals are named. This was already done after optimization passes, but also has to happen after LTO passes, as we always emit the final result in a ThinLTO-compatible manner. Fixes #51947.
2018-11-05Remove support for building against LLVM 4Nikita Popov-3/+1
With emscripten removed in #55626, we no longer need to support building against LLVM 4.
2018-11-05Auto merge of #55593 - nikic:remove-llvm-4-checks, r=rkruppebors-17/+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-03Move cg_llvm::back::linker to cg_utilsbjorn3-1695/+9
2018-11-02rustc: Wait for all codegen threads to exitAlex Crichton-6/+51
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-01Remove checks for LLVM < 4.0Nikita Popov-17/+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-23Revert "rustc: Fix (again) simd vectors by-val in ABI"Alex Crichton-38/+8
This reverts commit 3cc8f738d4247a9b475d8e074b621e602ac2b7be.
2018-10-20Rollup merge of #55073 - alexcrichton:demote-simd, r=nagisaManish Goregaokar-8/+38
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-1/+1
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-11/+3
2018-10-19Deprecate the `FxHashMap()` and `FxHashSet()` constructor function hackOliver Scherer-4/+4
2018-10-19rustc: Fix (again) simd vectors by-val in ABIAlex Crichton-8/+38
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-1/+1
2018-10-12raise ICE if LLVM worker threads panicAndy Russell-4/+2
2018-10-02wasm: Explicitly export all symbols with LLDAlex Crichton-1/+6
This commit fixes an oddity on the wasm target where LTO can produce working executables but plain old optimizations doesn't. The compiler already knows what set of symbols it would like to export, but LLD only discovers this list transitively through symbol visibilities. LLD may not, however, always find all the symbols that we'd like to export. For example if you depend on an rlib with a `#[no_mangle]` symbol, then if you don't actually use anything from the rlib then the symbol won't appear in the final artifact! It will appear, however, with LTO. This commit attempts to rectify this situation by ensuring that all symbols rustc would otherwise preserve through LTO are also preserved through the linking process with LLD by default.
2018-09-29rust: Add a `-C default-linker-libraries` optionAlex Crichton-6/+10
This commit adds a new codegen option for the compiler which disables rustc's passing of `-nodefaultlibs` by default on relevant platforms. Sometimes Rust is linked with C code which fails to link with `-nodefaultlibs` and is unnecessarily onerous to get linking correctly with `-nodefaultlibs`. An example of this is that when you compile C code with sanitizers and then pass `-fsanitize=address` to the linker, it's incompatible with `-nodefaultlibs` also being passed to the linker. In these situations it's easiest to turn off Rust's default passing of `-nodefaultlibs`, which was more ideological to start with than anything! Preserving the default is somewhat important but having this be opt-in shouldn't cause any breakage. Closes #54237
2018-09-28Move `filename_for_metadata` to codegen_utilsIgor Matuszewski-10/+2
This function isn't strictly tied to LLVM (it's more of a utility) and it's now near an analogous, almost identical `filename_for_input` (for rlibs and so forth). Also this means not depending on the backend when one wants to know the accurate .rmeta output filename.
2018-09-26add -Z emit-stack-sizesJorge Aparicio-0/+2
2018-09-23Auto merge of #54325 - michaelwoerister:incr-thinlto-tests, r=alexcrichtonbors-0/+9
incr.comp.: Allow for more fine-grained testing of CGU reuse and use it to test incremental ThinLTO. This adds some tests specifically targeted at incremental ThinLTO, plus the infrastructure for tracking the kind of cache hit/miss we had for a given CGU. @alexcrichton, let me know if you can think of any more tests to add. ThinLTO works rather reliably for small functions, so we should be able to test it in a robust way. I think after this lands it might time for a "Help us test incremental ThinLTO" post on irlo. r? @alexcrichton
2018-09-18incr.comp.: Allow for more fine-grained testing of CGU reuse and use it to ↵Michael Woerister-0/+9
test incremental ThinLTO.
2018-09-15Enable fatal warnings for the wasm32 linkerAlex Crichton-0/+4
Historically LLD has emitted warnings for various reasons but all the bugs have since been fixed (yay!) and by enabling fatal warnings we should be able to head off bugs like #53390 sooner.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 09:18:11 +0000