about summary refs log tree commit diff
path: root/compiler/rustc_codegen_ssa
AgeCommit message (Collapse)AuthorLines
2021-04-28Update list of allowed aarch64 featuresAdam Gemmell-2/+75
These features were recently added to std_detect. Features not supported by LLVM 9, the current minimum version for Rust, are commented.
2021-04-28Auto merge of #84498 - workingjubilee:update-grab-bag, r=Mark-Simulacrumbors-1/+1
Update grab bag This PR slides a bunch of crate versions forward until suddenly a bunch of deps fall out of the tree! In doing so this mostly picks up a version bump in the `redox_users` crate which makes most of the features default to optional. crossbeam-utils 0.7 => 0.8.3 (where applicable) https://github.com/crossbeam-rs/crossbeam/blob/master/crossbeam-utils/CHANGELOG.md directories 3.0.1 => 3.0.2 ignore 0.4.16 => 0.4.17 tempfile 3.0.5 => tempfile 3.2 Removes constant_time_eq from deps exceptions Removes arrayref from deps exceptions And also removes: - blake2b_simd - const_fn (the package, not the feature) - constant_time_eq - redox_users 0.3.4 - rust-argon2
2021-04-23Use tempfileJubilee Young-1/+1
2021-04-23Auto merge of #84339 - alexcrichton:llvm-fptoint-sat, r=nagisabors-133/+36
rustc: Use LLVM's new saturating float-to-int intrinsics This commit updates rustc, with an applicable LLVM version, to use LLVM's new `llvm.fpto{u,s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64, but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code, namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s,u}i` instructions which only get used for "out of bounds is undefined behavior". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions, but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches, but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version, but that will require sinking the complexity of it into other backends such as Cranelfit.
2021-04-21bump jobserver dependencyThe8472-1/+1
the newest jobserver version should slightly reduce context switches in highly parallel build environments on linux kernels >= 5.6
2021-04-21rustc: Use LLVM's new saturating float-to-int intrinsicsAlex Crichton-133/+36
This commit updates rustc, with an applicable LLVM version, to use LLVM's new `llvm.fpto{u,s}i.sat.*.*` intrinsics to implement saturating floating-point-to-int conversions. This results in a little bit tighter codegen for x86/x86_64, but the main purpose of this is to prepare for upcoming changes to the WebAssembly backend in LLVM where wasm's saturating float-to-int instructions will now be implemented with these intrinsics. This change allows simplifying a good deal of surrounding code, namely removing a lot of wasm-specific behavior. WebAssembly no longer has any special-casing of saturating arithmetic instructions and the need for `fptoint_may_trap` is gone and all handling code for that is now removed. This means that the only wasm-specific logic is in the `fpto{s,u}i` instructions which only get used for "out of bounds is undefined behavior". This does mean that for the WebAssembly target specifically the Rust compiler will no longer be 100% compatible with pre-LLVM 12 versions, but it seems like that's unlikely to be relied on by too many folks. Note that this change does immediately regress the codegen of saturating float-to-int casts on WebAssembly due to the specialization of the LLVM intrinsic not being present in our LLVM fork just yet. I'll be following up with an LLVM update to pull in those patches, but affects a few other SIMD things in flight for WebAssembly so I wanted to separate this change. Eventually the entire `cast_float_to_int` function can be removed when LLVM 12 is the minimum version, but that will require sinking the complexity of it into other backends such as Cranelfit.
2021-04-14Fix typos in rustc_codegen_ssa/src/back/write.rs.Edd Barrett-2/+2
2021-04-08Fix closed over variables not available in debuginfo for Windows MSVCWesley Wiser-15/+51
The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result, it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure. This fixes that by spilling additional variables to the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records.
2021-04-07Rollup merge of #83916 - Amanieu:asm_anonconst, r=petrochenkovDylan DPC-34/+30
Use AnonConst for asm! constants This replaces the old system which used explicit promotion. See #83169 for more background. The syntax for `const` operands is still the same as before: `const <expr>`. Fixes #83169 Because the implementation is heavily based on inline consts, we suffer from the same issues: - We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`. - We are hitting the same ICEs as inline consts, for example #78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
2021-04-06Use AnonConst for asm! constantsAmanieu d'Antras-34/+30
2021-04-05Rollup merge of #82483 - tmiasko:option-from-str, r=matthewjasperDylan DPC-1/+1
Use FromStr trait for number option parsing Replace `parse_uint` with generic `parse_number` based on `FromStr`. Use it for parsing inlining threshold to avoid casting later.
2021-04-05Rollup merge of #83820 - petrochenkov:nolinkargs, r=nagisaDylan DPC-10/+3
Remove attribute `#[link_args]` Closes https://github.com/rust-lang/rust/issues/29596 The attribute could always be replaced with `-C link-arg`, but cargo didn't provide a reasonable way to pass such flags to rustc. Now cargo supports `cargo:rustc-link-arg*` directives in build scripts (https://doc.rust-lang.org/cargo/reference/unstable.html#extra-link-arg), so this attribute can be removed.
2021-04-05Rollup merge of #80525 - devsnek:wasm64, r=nagisaDylan DPC-2/+2
wasm64 support There is still some upstream llvm work needed before this can land.
2021-04-04wasm64Gus Caplan-2/+2
2021-04-03Auto merge of #83811 - JohnTitor:rollup-hnw1xwz, r=JohnTitorbors-0/+1
Rollup of 7 pull requests Successful merges: - #82487 (Constify methods of `std::net::SocketAddr`, `SocketAddrV4` and `SocketAddrV6`) - #83756 (rustdoc: Rename internal uses of `spotlight`) - #83780 (Document "standard" conventions for error messages) - #83787 (Monomorphization doc fix) - #83803 (add fp-armv8 for ARM_ALLOWED_FEATURES) - #83804 (Remove nightly features in rustc_type_ir) - #83810 (Fix rustc_lint_defs documentation typo) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-04-03Remove attribute `#[link_args]`Vadim Petrochenkov-10/+3
2021-04-04Rollup merge of #83803 - surechen:add_target_feature, r=petrochenkovYuki Okushi-0/+1
add fp-armv8 for ARM_ALLOWED_FEATURES For fixing err in https://github.com/rust-lang/stdarch/pull/1105.
2021-04-03Auto merge of #83682 - bjorn3:mmap_wrapper, r=cjgillotbors-3/+4
Add an Mmap wrapper to rustc_data_structures This wrapper implements StableAddress and falls back to directly reading the file on wasm32. Taken from #83640, which I will close due to the perf regression.
2021-04-03add fp-armv8 for ARM_ALLOWED_FEATURESsurechen-0/+1
2021-04-03Auto merge of #83774 - richkadel:zero-based-counters, r=tmandrybors-17/+84
Translate counters from Rust 1-based to LLVM 0-based counter ids A colleague contacted me and asked why Rust's counters start at 1, when Clangs appear to start at 0. There is a reason why Rust's internal counters start at 1 (see the docs), and I tried to keep them consistent when codegenned to LLVM's coverage mapping format. LLVM should be tolerant of missing counters, but as my colleague pointed out, `llvm-cov` will silently fail to generate a coverage report for a function based on LLVM's assumption that the counters are 0-based. See: https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170 Apparently, if, for example, a function has no branches, it would have exactly 1 counter. `CounterValues.size()` would be 1, and (with the 1-based index), the counter ID would be 1. This would fail the check and abort reporting coverage for the function. It turns out that by correcting for this during coverage map generation, by subtracting 1 from the Rust Counter ID (both when generating the counter increment intrinsic call, and when adding counters to the map), some uncovered functions (including in tests) now appear covered! This corrects the coverage for a few tests! r? `@tmandry` FYI: `@wesleywiser`
2021-04-02Translate counters from Rust 1-based to LLVM 0-based counter idsRich Kadel-17/+84
A colleague contacted me and asked why Rust's counters start at 1, when Clangs appear to start at 0. There is a reason why Rust's internal counters start at 1 (see the docs), and I tried to keep them consistent when codegenned to LLVM's coverage mapping format. LLVM should be tolerant of missing counters, but as my colleague pointed out, `llvm-cov` will silently fail to generate a coverage report for a function based on LLVM's assumption that the counters are 0-based. See: https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170 Apparently, if, for example, a function has no branches, it would have exactly 1 counter. `CounterValues.size()` would be 1, and (with the 1-based index), the counter ID would be 1. This would fail the check and abort reporting coverage for the function. It turns out that by correcting for this during coverage map generation, by subtracting 1 from the Rust Counter ID (both when generating the counter increment intrinsic call, and when adding counters to the map), some uncovered functions (including in tests) now appear covered! This corrects the coverage for a few tests!
2021-04-03rm target specific logic in link_sanitizer_runtimeSimonas Kazlauskas-22/+14
2021-04-03Move SanitizerSet to rustc_targetSimonas Kazlauskas-5/+6
2021-03-30Add an Mmap wrapper to rustc_data_structuresbjorn3-3/+4
This wrapper implements StableAddress and falls back to directly reading the file on wasm32
2021-03-28linker: Use data execution prevention options by default when linker ↵Vadim Petrochenkov-0/+17
supports them
2021-03-28Auto merge of #83587 - petrochenkov:asneeded, r=nagisabors-0/+13
linker: Use `--as-needed` by default when linker supports it Do it in a centralized way in `link.rs` instead of individual target specs. Majority of relevant target specs were already passing it.
2021-03-28linker: Use `--as-needed` by default when linker supports itVadim Petrochenkov-0/+13
2021-03-26Use iter::zip in compiler/Josh Stone-3/+2
2021-03-25Auto merge of #83307 - richkadel:cov-unused-functions-1.1, r=tmandrybors-15/+42
coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple, somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable, but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program, it increased the size by about 40%. I have not tested large programs, but there is anecdotal evidence that profraw files were way too large. This is a good fix, regardless, but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR when compiled with coverage, and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions, making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions, including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR, sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function, even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance, and generates dedicated instances for each unused function. This change, and a few other adjustments (similar to what is required for `-C link-dead-code`, but with lower impact), makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: "Unexecuted instantiation:..." for a generic function from multiple crates Fixed by removing the aforementioned hack. Some "Unexecuted instantiation" notices are unavoidable, as explained in the `used_crate.rs` test, but `-Zinstrument-coverage` has new options to back off support for either unused generics, or all unused functions, which avoids the notice, at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining, if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)], and in some cases, the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`
2021-03-23Changes from review commentsRich Kadel-15/+4
2021-03-22Auto merge of #79278 - mark-i-m:stabilize-or-pattern, r=nikomatsakisbors-1/+1
Stabilize or_patterns (RFC 2535, 2530, 2175) closes #54883 This PR stabilizes the or_patterns feature in Rust 1.53. This is blocked on the following (in order): - [x] The crater run in https://github.com/rust-lang/rust/pull/78935#issuecomment-731564021 - [x] The resolution of the unresolved questions and a second crater run (https://github.com/rust-lang/rust/pull/78935#issuecomment-735412705) - It looks like we will need to pursue some sort of edition-based transition for `:pat`. - [x] Nomination and discussion by T-lang - [x] Implement new behavior for `:pat` based on consensus (https://github.com/rust-lang/rust/pull/80100). - [ ] An FCP on stabilization EDIT: Stabilization report is in https://github.com/rust-lang/rust/pull/79278#issuecomment-772815177
2021-03-20update `const_eval_resolve`lcnr-2/+2
2021-03-20extract `ConstKind::Unevaluated` into a structlcnr-1/+1
2021-03-19gave unused_fn WeakAnyLinkage; moved create_pgo_func_name_varRich Kadel-4/+0
The sample json5format tests produce coverage results again (and work with opt-level 3!)
2021-03-19stabilize or_patternsmark-1/+1
2021-03-19coverage bug fixes and optimization supportRich Kadel-15/+57
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple, somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable, but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program, it increased the size by about 40%. I have not tested large programs, but there is anecdotal evidence that profraw files were way too large. This is a good fix, regardless, but hopefully it also addresses related issues. Fixes: #82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR when compiled with coverage, and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions, making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions, including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR, sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function, even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance, and generates dedicated instances for each unused function. This change, and a few other adjustments (similar to what is required for `-C link-dead-code`, but with lower impact), makes it possible to support LLVM optimizations. Fixes: #79651 Coverage report: "Unexecuted instantiation:..." for a generic function from multiple crates Fixed by removing the aforementioned hack. Some "Unexecuted instantiation" notices are unavoidable, as explained in the `used_crate.rs` test, but `-Zinstrument-coverage` has new options to back off support for either unused generics, or all unused functions, which avoids the notice, at the cost of less coverage of unused functions. Fixes: #82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining, if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)], and in some cases, the forced inlining breaks coverage instrumentation and reports.
2021-03-19Rollup merge of #83236 - cjgillot:memmap, r=joshtriplettDylan DPC-3/+3
Upgrade memmap to memmap2 memmap is no longer maintained. memmap2 is a fork that is still maintained. https://rustsec.org/advisories/RUSTSEC-2020-0077.html The remaining use of memmap is through measureme.
2021-03-18Upgrade memmap to memmap2 in other crates.Camille GILLOT-3/+3
2021-03-18Remove unwrap_none/expect_none from compiler/.Mara Bos-1/+1
2021-03-18Rollup merge of #83080 - tmiasko:inline-coverage, r=wesleywiserDylan DPC-13/+35
Make source-based code coverage compatible with MIR inlining When codegenning code coverage use the instance that coverage data was originally generated for, to ensure basic level of compatibility with MIR inlining. Fixes #83061
2021-03-16Auto merge of #82936 - oli-obk:valtree, r=RalfJung,lcnr,matthewjasperbors-12/+13
Implement (but don't use) valtree and refactor in preparation of use This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes. cc `@rust-lang/wg-const-eval` on the following commits: * 2027184 implement valtree * eeecea9 fallible Scalar -> ScalarInt * 042f663 ScalarInt convenience methods cc `@eddyb` on ef04a6d cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const`, and it is totally possible to have two different representations for the same value)
2021-03-15Make source-based code coverage compatible with MIR inliningTomasz Miąsko-13/+35
When codegenning code coverage use the instance that coverage data was originally generated for, to ensure basic level of compatibility with MIR inlining.
2021-03-15s/ConstantSource/ConstantKind/Oli Scherer-2/+2
2021-03-13Do not emit alloca for ZST local even if it is uninitializedSimon Vandel Sillesen-1/+12
2021-03-13Rollup merge of #83020 - hi-rustin:rustin-patch-enum, r=lcnrYuki Okushi-1/+1
Emit the enum range assumption if the range only contains one element close https://github.com/rust-lang/rust/issues/82871
2021-03-12Prepare mir::Constant for ty::Const only supporting valtreesOli Scherer-2/+7
2021-03-12Add `ty` helper function for mir constantsOli Scherer-10/+6
This is in preparation of the `literal` field becoming an enum that distinguishes between type level constants and runtime constants
2021-03-12Emit the enum range assumption if the range only contains one elementhi-rustin-1/+1
test: add test case make tidy happy
2021-03-11Adjust some `#[cfg]`s to take non-Unix non-Windows operating systems into ↵hyd-dev-2/+7
account
2021-03-10Auto merge of #82884 - nagisa:nagisa/remove-most-of-sideeffect-inserts, r=nikicbors-55/+12
Remove the -Zinsert-sideeffect This removes all of the code we had in place to work-around LLVM's handling of forward progress. From this removal excluded is a workaround where we'd insert a `sideeffect` into clearly infinite loops such as `loop {}`. This code remains conditionally effective when the LLVM version is earlier than 12.0, which fixed the forward progress related miscompilations at their root.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 14:36:30 +0000