about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src
AgeCommit message (Collapse)AuthorLines
2023-06-16Rollup merge of #112474 - ldm0:ldm_enum_debuginfo_128_support, r=compiler-errorsMichael Goulet-8/+6
Support 128-bit enum variant in debuginfo codegen fixes #111600
2023-06-14Introduce a minimum CGU size in non-incremental builds.Nicholas Nethercote-1/+1
Because tiny CGUs make compilation less efficient *and* result in worse generated code. We don't do this when the number of CGUs is explicitly given, because there are times when the requested number is very important, as described in some comments within the commit. So the commit also introduces a `CodegenUnits` type that distinguishes between default values and user-specified values. This change has a roughly neutral effect on walltimes across the rustc-perf benchmarks; there are some speedups and some slowdowns. But it has significant wins for most other metrics on numerous benchmarks, including instruction counts, cycles, binary size, and max-rss. It also reduces parallelism, which is good for reducing jobserver competition when multiple rustc processes are running at the same time. It's smaller benchmarks that benefit the most; larger benchmarks already have CGUs that are all larger than the minimum size. Here are some example before/after CGU sizes for opt builds. - html5ever - CGUs: 16, mean size: 1196.1, sizes: [3908, 2992, 1706, 1652, 1572, 1136, 1045, 948, 946, 938, 579, 471, 443, 327, 286, 189] - CGUs: 4, mean size: 4396.0, sizes: [6706, 3908, 3490, 3480] - libc - CGUs: 12, mean size: 35.3, sizes: [163, 93, 58, 53, 37, 8, 2 (x6)] - CGUs: 1, mean size: 424.0, sizes: [424] - tt-muncher - CGUs: 5, mean size: 1819.4, sizes: [8508, 350, 198, 34, 7] - CGUs: 1, mean size: 9075.0, sizes: [9075] Note that CGUs of size 100,000+ aren't unusual in larger programs.
2023-06-10Support 128-bit enum variant in debuginfo codegenDonoughLiu-8/+6
2023-06-08Auto merge of #110040 - ndrewxie:issue-84447-partial-1, r=lcnr,michaelwoeristerbors-2/+2
Removed use of iteration through a HashMap/HashSet in rustc_incremental and replaced with IndexMap/IndexSet This allows for the `#[allow(rustc::potential_query_instability)]` in rustc_incremental to be removed, moving towards fixing #84447 (although a LOT more modules have to be changed to fully resolve it). Only HashMaps/HashSets that are being iterated through have been modified (although many structs and traits outside of rustc_incremental had to be modified as well, as they had fields/methods that involved a HashMap/HashSet that would be iterated through) I'm making a PR for just 1 module changed to test for performance regressions and such, for future changes I'll either edit this PR to reflect additional modules being converted, or batch multiple modules of changes together and make a PR for each group of modules.
2023-06-04Removed use of iteration through a HashMap/HashSet in rustc_incremental and ↵Andrew Xie-2/+2
replaced with IndexMap/IndexSet
2023-06-04Use `load`-`store` instead of `memcpy` for short integer arraysScott McMurray-0/+36
2023-06-02Rollup merge of #111647 - klensy:cstr, r=oli-obkMatthias Krüger-59/+48
use c literals in compiler and library Use c literals #108801 in compiler and library currently blocked on: * <strike>rustfmt: don't know how to format c literals</strike> nope, nightly one works. * <strike>bootstrap</strike> r? `@ghost` `@rustbot` blocked
2023-06-01Use translatable diagnostics in `rustc_const_eval`Deadbeef-21/+27
2023-05-31Add a distinct `OperandValue::ZeroSized` variant for ZSTsScott McMurray-3/+2
These tend to have special handling in a bunch of places anyway, so the variant helps remember that. And I think it's easier to grok than non-Scalar Aggregates sometimes being `Immediates` (like I got wrong and caused 109992). As a minor bonus, it means we don't need to generate poison LLVM values for them to pass around in `OperandValue::Immediate`s.
2023-05-31use new c literals instead of cstr! macroklensy-59/+48
2023-05-30Auto merge of #112102 - Nilstrieb:rollup-ivu1hmc, r=Nilstriebbors-1/+1
Rollup of 7 pull requests Successful merges: - #107916 (fix comment on Allocator trait) - #111543 (Uplift `clippy::invalid_utf8_in_unchecked` lint) - #111872 (fix: dedup `static_candidates` before report) - #111955 (bootstrap: Various Step refactors) - #112060 (`EarlyBinder::new` -> `EarlyBinder::bind`) - #112064 (Migrate GUI colors test to original CSS color format) - #112100 (Don't typecheck recovered method call from suggestion) r? `@ghost` `@rustbot` modify labels: rollup
2023-05-30Auto merge of #111768 - oli-obk:pair_const_llvm, r=cjgillotbors-32/+17
Optimize scalar and scalar pair representations loaded from ByRef in llvm in https://github.com/rust-lang/rust/pull/105653 I noticed that we were generating suboptimal LLVM IR if we had a `ConstValue::ByRef` that could be represented by a `ScalarPair`. Before https://github.com/rust-lang/rust/pull/105653 this is probably rare, but after it, every slice will go down this suboptimal code path that requires LLVM to untangle a bunch of indirections and translate static allocations that are only used once to read a scalar pair from.
2023-05-29EarlyBinder::new -> EarlyBinder::bindlcnr-1/+1
2023-05-28Replace EarlyBinder(x) with EarlyBinder::new(x)Kyle Matsuda-1/+1
2023-05-26Add SafeStack support to rustcWesley Wiser-0/+4
Adds support for LLVM [SafeStack] which provides backward edge control flow protection by separating the stack into two parts: data which is only accessed in provable safe ways is allocated on the normal stack (the "safe stack") and all other data is placed in a separate allocation (the "unsafe stack"). SafeStack support is enabled by passing `-Zsanitizer=safestack`. [SafeStack]: https://clang.llvm.org/docs/SafeStack.html
2023-05-26Stop creating intermediate places just to immediate convert them to operandsOli Scherer-32/+17
2023-05-25Auto merge of #86844 - bjorn3:global_alloc_improvements, r=pnkfelixbors-66/+79
Support #[global_allocator] without the allocator shim This makes it possible to use liballoc/libstd in combination with `--emit obj` if you use `#[global_allocator]`. This is what rust-for-linux uses right now and systemd may use in the future. Currently they have to depend on the exact implementation of the allocator shim to create one themself as `--emit obj` doesn't create an allocator shim. Note that currently the allocator shim also defines the oom error handler, which is normally required too. Once `#![feature(default_alloc_error_handler)]` becomes the only option, this can be avoided. In addition when using only fallible allocator methods and either `--cfg no_global_oom_handling` for liballoc (like rust-for-linux) or `--gc-sections` no references to the oom error handler will exist. To avoid this feature being insta-stable, you will have to define `__rust_no_alloc_shim_is_unstable` to avoid linker errors. (Labeling this with both T-compiler and T-lang as it originally involved both an implementation detail and had an insta-stable user facing change. As noted above, the `__rust_no_alloc_shim_is_unstable` symbol requirement should prevent unintended dependence on this unstable feature.)
2023-05-24Use `is_some_and`/`is_ok_and` in less obvious spotsMaybe Waffle-2/+1
2023-05-24Use `Option::is_some_and` and `Result::is_ok_and` in the compilerMaybe Waffle-1/+1
2023-05-22Create a structure to define the features from to_llvm_features.Jamie Cunliffe-65/+128
Rather than returning an array of features from to_llvm_features, return a structure that contains the dependencies. This also contains metadata on how the features depend on each other to allow for the correct enabling and disabling.
2023-05-22Only disable folded features when it makes sense.Jamie Cunliffe-5/+31
Some features that are tied together only make sense to be folded together when enabling the feature. For example on AArch64 sve and neon are tied together, however it doesn't make sense to disable neon when disabling sve.
2023-05-22Tie neon with fp-armv8.Jamie Cunliffe-2/+4
In #91608 the fp-armv8 feature was removed as it's tied to the neon feature. However disabling neon didn't actually disable the use of floating point registers and instructions, for this `-fp-armv8` is required.
2023-05-19Auto merge of #111641 - michaelwoerister:debugger-visualizer-fixes, r=cjgillotbors-2/+1
Fix dependency tracking for debugger visualizers This PR fixes dependency tracking for debugger visualizer files by changing the `debugger_visualizers` query to an `eval_always` query that scans the AST while it is still available. This way the set of visualizer files is already available when dep-info is emitted. Since the query is turned into an `eval_always` query, dependency tracking will now reliably detect changes to the visualizer script files themselves. TODO: - [x] perf.rlo - [x] Needs a bit more documentation in some places - [x] Needs regression test for the incr. comp. case Fixes https://github.com/rust-lang/rust/issues/111226 Fixes https://github.com/rust-lang/rust/issues/111227 Fixes https://github.com/rust-lang/rust/issues/111295 r? `@wesleywiser` cc `@gibbyfree`
2023-05-18Auto merge of #111345 - jyn514:cfg-release-caching, r=cjgillot,est31bors-2/+1
Only depend on CFG_VERSION in rustc_interface This avoids having to rebuild the whole compiler on each commit when `omit-git-hash = false`. cc https://github.com/rust-lang/rust/issues/76720 - this won't fix it, and I'm not suggesting we turn this on by default, but it will make it less painful for people who do have `omit-git-hash` on as a workaround.
2023-05-17Only depend on CFG_VERSION in rustc_interfacejyn-2/+1
this avoids having to rebuild the whole compiler on each commit when `omit-git-hash = false`.
2023-05-18Auto merge of #111364 - cuviper:unhack-thinlto, r=nikicbors-55/+0
Remove the ThinLTO CU hack This reverts #46722, commit e0ab5d5feb4eb2d8af11b8dd9446c2b45fada8af. Since #111167, commit 10b69dde3fd15334ea2382d2dc9e9a261de1afaf, we are generating DWARF subprograms in a way that is meant to be more compatible with LLVM's expectations, so hopefully we don't need this workaround rewriting CUs anymore.
2023-05-16Move DebuggerVisualizerFile types from rustc_span to rustc_middleMichael Woerister-2/+1
2023-05-15Auto merge of #107707 - calebzulawski:remove-features, r=Amanieubors-6/+0
Remove misleading target feature aliases Fixes #100752. This is a follow up to #103750. These aliases could not be completely removed until rust-lang/stdarch#1355 landed. cc `@Amanieu`
2023-05-15Move expansion of query macros in rustc_middle to rustc_middle::queryJohn Kåre Alsaker-1/+1
2023-05-11Rollup merge of #111375 - rcvalle:rust-cfi-fix-106547, r=bjorn3Michael Goulet-21/+52
CFI: Fix SIGILL reached via trait objects Fix #106547 by transforming the concrete self into a reference to a trait object before emitting type metadata identifiers for trait methods.
2023-05-11Prevent insta-stable no alloc shim supportbjorn3-1/+9
You will need to add the following as replacement for the old __rust_* definitions when not using the alloc shim. #[no_mangle] static __rust_no_alloc_shim_is_unstable: u8 = 0;
2023-05-11Use global_fn_name instead of format!bjorn3-2/+3
2023-05-11Split AllocatorKind::fn_name in global_fn_name and default_fn_namebjorn3-2/+2
2023-05-11Don't use an allocator shim for `#[global_allocator]`bjorn3-66/+70
This makes it possible to use liballoc/libstd in combination with `--emit obj` if you use `#[global_allocator]`. Making it work for the default libstd allocator would require weak functions, which are not well supported on all systems.
2023-05-09CFI: Fix SIGILL reached via trait objectsRamon de C Valle-21/+52
Fix #106547 by transforming the concrete self into a reference to a trait object before emitting type metadata identifiers for trait methods.
2023-05-09Isolate coverage FFI type layouts from their underlying LLVM C++ typesZalathar-2/+6
2023-05-08Remove the ThinLTO CU hackJosh Stone-55/+0
This reverts #46722, commit e0ab5d5feb4eb2d8af11b8dd9446c2b45fada8af. Since #111167, commit 10b69dde3fd15334ea2382d2dc9e9a261de1afaf, we are generating DWARF subprograms in a way that is meant to be more compatible with LLVM's expectations, so hopefully we don't need this workaround rewriting CUs anymore.
2023-05-08Rollup merge of #104070 - nbdd0121:unwind, r=AmanieuMichael Goulet-1/+8
Prevent aborting guard from aborting the process in a forced unwind Fix #101469
2023-05-08Rollup merge of #111332 - loongarch-rs:inline-asm, r=AmanieuYuki Okushi-1/+12
Improve inline asm for LoongArch This PR is a sub-part of https://github.com/rust-lang/rust/pull/111235, to improve inline asm for LoongArch. r? `@Amanieu`
2023-05-08Rollup merge of #111331 - taiki-e:s390x-asm-cc, r=AmanieuYuki Okushi-1/+3
Mark s390x condition code register as clobbered in inline assembly Various s390x instructions (arithmetic operations, logical operations, comparisons, etc. see also "Condition Codes" section in [z/Architecture Reference Summary](https://www.ibm.com/support/pages/zarchitecture-reference-summary)) modify condition code register `cc`, but AFAIK there is currently no way to mark it as clobbered in `asm!`. `cc` register definition in LLVM: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L320 This PR also updates asm_experimental_arch docs in the unstable-book to mention s390x registers. cc `@uweigand` r? `@Amanieu`
2023-05-08Mark s390x condition code register as clobbered in inline assemblyTaiki Endo-1/+3
2023-05-08Mark LoongArch float-point condition flags as clobbered in inline assemblyWANG Rui-1/+12
2023-05-07Fix num reserved clauses for landing padGary Guo-2/+2
2023-05-07Use `landingpad filter` to encode aborting landing padGary Guo-0/+7
2023-05-06make (try_)subst_and_normalize_erasing_regions take EarlyBinderKyle Matsuda-2/+2
2023-05-06Rollup merge of #111203 - Kobzol:remark-print-kind, r=tmiaskoMatthias Krüger-0/+11
Output LLVM optimization remark kind in `-Cremark` output Since https://github.com/rust-lang/rust/pull/90833, the optimization remark kind has not been printed. Therefore it wasn't possible to easily determine from the log (in a programmatic way) which remark kind was produced. I think that the most interesting remarks are the missed ones, which can lead users to some code optimization. Maybe we could also change the format closer to the "old" one: ``` note: optimization remark for tailcallelim at /checkout/src/libcore/num/mod.rs:1:0: marked this call a tail call candidate ``` I wanted to programatically parse the remarks so that they could work e.g. with https://github.com/OfekShilon/optview2. However, now that I think about it, probably the proper solution is to tell rustc to output them to YAML and then use the YAML as input for the opt remark visualization tools. The flag for enabling this does not seem to work though (https://github.com/rust-lang/rust/issues/96705#issuecomment-1117632322). Still I think that it's good to output the remark kind anyway, it's an important piece of information. r? ```@tmiasko```
2023-05-06Rollup merge of #111167 - cuviper:type-decl-disubprogram, r=michaelwoeristerMatthias Krüger-34/+66
debuginfo: split method declaration and definition When we're adding a method to a type DIE, we only want a DW_AT_declaration there, because LLVM LTO can't unify type definitions when a child DIE is a full subprogram definition. Now the subprogram definition gets added at the CU level with a specification link back to the abstract declaration. Both GCC and Clang write debuginfo this way for C++ class methods. Fixes #109730. Fixes #109934.
2023-05-06Rollup merge of #109677 - dpaoliello:rawdylib, r=michaelwoerister,wesleywiserYuki Okushi-5/+10
Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (https://github.com/rust-lang/rust/pull/104218#issuecomment-1315895618) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: https://github.com/rust-lang/rust/pull/104218#issuecomment-1318720482 Big thanks to ``````@tbu-`````` for the first version of this PR (#104218)
2023-05-04added SAFETY commentJames Dietz-0/+3
2023-05-04change expect() to unwrap_or_else() and update msgJames Dietz-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-12-02 18:49:52 +0000