about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm
AgeCommit message (Collapse)AuthorLines
2021-03-22Rollup merge of #83329 - camelid:debuginfo-doc-cleanup, r=davidtwcoDylan DPC-181/+182
Cleanup LLVM debuginfo module docs - Move debuginfo docs from `doc.rs` module to `doc.md` file - Cleanup LLVM debuginfo module docs
2021-03-21Enable mutable noalias by default for LLVM 12Nikita Popov-12/+10
We don't have any known noalias bugs for LLVM 12 ... yet.
2021-03-21Convert -Z mutable-noalias to Optional<bool>Nikita Popov-1/+1
The default value will dependend on the LLVM version in the future, so don't specify one to start with.
2021-03-21Move decision aboute noalias into codegen_llvmNikita Popov-18/+49
The frontend shouldn't be deciding whether or not to use mutable noalias attributes, as this is a pure LLVM concern. Only provide the necessary information and do the actual decision in codegen_llvm.
2021-03-20Cleanup LLVM debuginfo module docsCamelid-14/+15
* Use Markdown list syntax and unindent a bit to prevent Markdown interpreting the nested lists as code blocks * A few more small typographical cleanups
2021-03-20Move debuginfo docs from `doc.rs` module to `doc.md` fileCamelid-181/+181
And use `#[doc = include_str!("doc.md")]` in `mod.rs` so the docs are rendered as if they were inline in the root module.
2021-03-19correct macro namesSparrowLii-4/+4
2021-03-19Add simd_neg platform intrinsicSparrowLii-2/+21
2021-03-18Rollup merge of #83080 - tmiasko:inline-coverage, r=wesleywiserDylan DPC-2/+2
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-17Auto merge of #83084 - nagisa:nagisa/features-native, r=petrochenkovbors-34/+67
Adjust `-Ctarget-cpu=native` handling in cg_llvm When cg_llvm encounters the `-Ctarget-cpu=native` it computes an explciit set of features that applies to the target in order to correctly compile code for the host CPU (because e.g. `skylake` alone is not sufficient to tell if some of the instructions are available or not). However there were a couple of issues with how we did this. Firstly, the order in which features were overriden wasn't quite right – conceptually you'd expect `-Ctarget-cpu=native` option to override the features that are implicitly set by the target definition. However due to how other `-Ctarget-cpu` values are handled we must adopt the following order of priority: * Features from -Ctarget-cpu=*; are overriden by * Features implied by --target; are overriden by * Features from -Ctarget-feature; are overriden by * function specific features. Another problem was in that the function level `target-features` attribute would overwrite the entire set of the globally enabled features, rather than just the features the `#[target_feature(enable/disable)]` specified. With something like `-Ctarget-cpu=native` we'd end up in a situation wherein a function without `#[target_feature(enable)]` annotation would have a broader set of features compared to a function with one such attribute. This turned out to be a cause of heavy run-time regressions in some code using these function-level attributes in conjunction with `-Ctarget-cpu=native`, for example. With this PR rustc is more careful about specifying the entire set of features for functions that use `#[target_feature(enable/disable)]` or `#[instruction_set]` attributes. Sadly testing the original reproducer for this behaviour is quite impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in particular on developer or CI machines. cc https://github.com/rust-lang/rust/issues/83027 `@BurntSushi`
2021-03-16Adjust `-Ctarget-cpu=native` handling in cg_llvmSimonas Kazlauskas-34/+67
When cg_llvm encounters the `-Ctarget-cpu=native` it computes an explciit set of features that applies to the target in order to correctly compile code for the host CPU (because e.g. `skylake` alone is not sufficient to tell if some of the instructions are available or not). However there were a couple of issues with how we did this. Firstly, the order in which features were overriden wasn't quite right – conceptually you'd expect `-Ctarget-cpu=native` option to override the features that are implicitly set by the target definition. However due to how other `-Ctarget-cpu` values are handled we must adopt the following order of priority: * Features from -Ctarget-cpu=*; are overriden by * Features implied by --target; are overriden by * Features from -Ctarget-feature; are overriden by * function specific features. Another problem was in that the function level `target-features` attribute would overwrite the entire set of the globally enabled features, rather than just the features the `#[target_feature(enable/disable)]` specified. With something like `-Ctarget-cpu=native` we'd end up in a situation wherein a function without `#[target_feature(enable)]` annotation would have a broader set of features compared to a function with one such attribute. This turned out to be a cause of heavy run-time regressions in some code using these function-level attributes in conjunction with `-Ctarget-cpu=native`, for example. With this PR rustc is more careful about specifying the entire set of features for functions that use `#[target_feature(enable/disable)]` or `#[instruction_set]` attributes. Sadly testing the original reproducer for this behaviour is quite impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in particular on developer or CI machines.
2021-03-16Auto merge of #82838 - Amanieu:rustdoc_asm, r=nagisabors-0/+3
Allow rustdoc to handle asm! of foreign architectures This allows rustdoc to process code containing `asm!` for architectures other than the current one. Since this never reaches codegen, we just replace target-specific registers and register classes with a dummy one. Fixes #82869
2021-03-15Functions inlined into reachable functions are reachableTomasz Miąsko-1/+1
Consider functions to be reachable for code coverage purposes, either when they reach the code generation directly, or indirectly as inlined part of another function.
2021-03-15Make source-based code coverage compatible with MIR inliningTomasz Miąsko-1/+1
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-13Always lower asm! to valid HIRAmanieu d'Antras-0/+3
2021-03-12Add support for storing code model to LLVM module IRHiroki Noda-1/+10
This patch avoids undefined behavior by linking different object files. Also this would it could be propagated properly to LTO. See https://reviews.llvm.org/D52322 and https://reviews.llvm.org/D52323. This patch is based on https://github.com/rust-lang/rust/pull/74002
2021-03-10Remove the -Zinsert-sideeffectSimonas Kazlauskas-9/+5
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.
2021-03-07Auto merge of #82285 - nhwn:nonzero-debug, r=nagisabors-25/+15
Use u32 over Option<u32> in DebugLoc ~~Changes `Option<u32>` fields in `DebugLoc` to `Option<NonZeroU32>`. Since the respective fields (`line` and `col`) are guaranteed to be 1-based, this layout optimization is a freebie.~~ EDIT: Changes `Option<u32>` fields in `DebugLoc` to `u32`. As `@bugadani` pointed out, an `Option<NonZeroU32>` is probably an unnecessary layer of abstraction since the `None` variant is always used as `UNKNOWN_LINE_NUMBER` (which is just `0`). Also, `SourceInfo` in `metadata.rs` already uses a `u32` instead of an `Option<u32>` to encode the same information, so I think this change is warranted. Since `@jyn514` raised some concerns over measuring performance in a similar PR (#82255), does this need a perf run?
2021-03-04Auto merge of #81451 - nikic:llvm-12, r=nagisabors-9/+31
Upgrade to LLVM 12 This implements the necessary adjustments to make rustc work with LLVM 12. I didn't encounter any major issues so far. r? `@cuviper`
2021-03-01Mark pure asm as willreturnNikita Popov-0/+2
2021-03-01Don't directly expose coverage::CounterMappingRegion via FFINikita Popov-6/+4
The definition of this struct changes in LLVM 12 due to the addition of branch coverage support. To avoid future mismatches, declare our own struct and then convert between them.
2021-03-01Box generator-related Body fieldsDániel Buga-1/+1
2021-02-28Support LLVM 12 in rustcNikita Popov-3/+25
2021-02-27Rollup merge of #82537 - wesleywiser:update_measureme, r=oli-obkDylan DPC-1/+1
Update measureme dependency to the latest version This version adds the ability to use `rdpmc` hardware-based performance counters instead of wall-clock time for measuring duration. This also introduces a dependency on the `perf-event-open-sys` crate on Linux which is used when using hardware counters. r? ```@oli-obk```
2021-02-27Rollup merge of #82057 - upsuper-forks:cstr, r=davidtwco,wesleywiserDylan DPC-29/+30
Replace const_cstr with cstr crate This PR replaces the `const_cstr` macro inside `rustc_data_structures` with `cstr` macro from [cstr](https://crates.io/crates/cstr) crate. The two macros basically serve the same purpose, which is to generate `&'static CStr` from a string literal. `cstr` is better because it validates the literal at compile time, while the existing `const_cstr` does it at runtime when `debug_assertions` is enabled. In addition, the value `cstr` generates can be used in constant context (which is seemingly not needed anywhere currently, though).
2021-02-26Rollup merge of #82456 - klensy:or-else, r=estebankGuillaume Gomez-6/+6
Replaced some unwrap_or and map_or with lazy variants Replaced some `unwrap_or` and `map_or` with `unwrap_or_else` and `map_or_else`.
2021-02-25Update measureme dependency to the latest versionWesley Wiser-1/+1
This version adds the ability to use `rdpmc` hardware-based performance counters instead of wall-clock time for measuring duration. This also introduces a dependency on the `perf-event-open-sys` crate on Linux which is used when using hardware counters.
2021-02-25Rollup merge of #82214 - est31:no_to_string, r=oli-obkDylan DPC-1/+1
Remove redundant to_string calls
2021-02-25Rollup merge of #82213 - est31:slices_for_vecs, r=jyn514Dylan DPC-3/+3
Slices for vecs
2021-02-25fix reviewklensy-6/+5
2021-02-24replaced some map_or with map_or_elseklensy-6/+7
2021-02-23Auto merge of #82102 - nagisa:nagisa/fix-dwo-name, r=davidtwcobors-9/+12
Set path of the compile unit to the source directory As part of the effort to implement split dwarf debug info, we ended up setting the compile unit location to the output directory rather than the source directory. Furthermore, it seems like we failed to remap the prefixes for this as well! The desired behaviour is to instead set the `DW_AT_GNU_dwo_name` to a path relative to compiler's working directory. This still allows debuggers to find the split dwarf files, while not changing the behaviour of the code that is compiling with regular debug info, and not changing the compiler's behaviour with regards to reproducibility. Fixes #82074 cc `@alexcrichton` `@davidtwco`
2021-02-20nhwn: use plain u32 in DebugLocNathan Nguyen-26/+15
2021-02-20nhwn: use Option<NonZeroU32> in DebugLocNathan Nguyen-12/+13
2021-02-17Rollup merge of #82105 - nagisa:nagisa/ensure-removed, r=petrochenkovGuillaume Gomez-3/+2
Don't fail to remove files if they are missing In the backend we may want to remove certain temporary files, but in certain other situations these files might not be produced in the first place. We don't exactly care about that, and the intent is really that these files are gone after a certain point in the backend. Here we unify the backend file removing calls to use `ensure_removed` which will attempt to delete a file, but will not fail if it does not exist (anymore). The tradeoff to this approach is, of course, that we may miss instances were we are attempting to remove files at wrong paths due to some bug – compilation would silently succeed but the temporary files would remain there somewhere.
2021-02-17Remove redundant to_string callsest31-1/+1
2021-02-17Replace vec![] calls with slice literalsest31-3/+3
There is no need to create vec's here
2021-02-1432-bit ARM: Emit `lr` instead of `r14` when specified as an `asm!` output ↵Johnathan Van Why-0/+3
register. On 32-bit ARM platforms, the register `r14` has the alias `lr`. When used as an output register in `asm!`, rustc canonicalizes the name to `r14`. LLVM only knows the register by the name `lr`, and rejects it. This changes rustc's LLVM code generation to output `lr` instead.
2021-02-14Don't fail to remove files if they are missingSimonas Kazlauskas-3/+2
In the backend we may want to remove certain temporary files, but in certain other situations these files might not be produced in the first place. We don't exactly care about that, and the intent is really that these files are gone after a certain point in the backend. Here we unify the backend file removing calls to use `ensure_removed` which will attempt to delete a file, but will not fail if it does not exist (anymore). The tradeoff to this approach is, of course, that we may miss instances were we are attempting to remove files at wrong paths due to some bug – compilation would silently succeed but the temporary files would remain there somewhere.
2021-02-14Set path of the compile unit to the source directorySimonas Kazlauskas-9/+12
As part of the effort to implement split dwarf debug info, we ended up setting the compile unit location to the output directory rather than the source directory. Furthermore, it seems like we failed to remap the prefixes for this as well! The desired behaviour is to instead set the `DW_AT_GNU_dwo_name` to a path relative to compiler's working directory. This still allows debuggers to find the split dwarf files, while not changing the behaviour of the code that is compiling with regular debug info, and not changing the compiler's behaviour with regards to reproducibility. Fixes #82074
2021-02-14bumped smallvec depsklensy-1/+1
2021-02-14Replace const_cstr with cstr crateXidorn Quan-29/+30
2021-02-07HWASan supportTri Vo-0/+13
2021-02-07Auto merge of #80652 - calebzulawski:simd-lanes, r=nagisabors-209/+82
Improve SIMD type element count validation Resolves rust-lang/stdsimd#53. These changes are motivated by `stdsimd` moving in the direction of const generic vectors, e.g.: ```rust #[repr(simd)] struct SimdF32<const N: usize>([f32; N]); ``` This makes a few changes: * Establishes a maximum SIMD lane count of 2^16 (65536). This value is arbitrary, but attempts to validate lane count before hitting potential errors in the backend. It's not clear what LLVM's maximum lane count is, but cranelift's appears to be much less than `usize::MAX`, at least. * Expands some SIMD intrinsics to support arbitrary lane counts. This resolves the ICE in the linked issue. * Attempts to catch invalid-sized vectors during typeck when possible. Unresolved questions: * Generic-length vectors can't be validated in typeck and are only validated after monomorphization while computing layout. This "works", but the errors simply bail out with no context beyond the name of the type. Should these errors instead return `LayoutError` or otherwise provide context in some way? As it stands, users of `stdsimd` could trivially produce monomorphization errors by making zero-length vectors. cc `@bjorn3`
2021-02-06Rollup merge of #81664 - bjorn3:no_codegen_hir, r=lcnrMara Bos-56/+24
Avoid a hir access inside get_static Together with #81056 this ensures that the codegen unit DepNode doesn't have a direct dependency on any part of the hir.
2021-02-04Use is_local instead of as_localbjorn3-2/+2
2021-02-03Auto merge of #81346 - hug-dev:nonsecure-call-abi, r=jonas-schievinkbors-1/+18
Add a new ABI to support cmse_nonsecure_call This adds support for the `cmse_nonsecure_call` feature to be able to perform non-secure function call. See the discussion on Zulip [here](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Support.20for.20callsite.20attributes/near/223054928). This is a followup to #75810 which added `cmse_nonsecure_entry`. As for that PR, I assume that the changes are small enough to not have to go through a RFC but I don't mind doing one if needed 😃 I did not yet create a tracking issue, but if most of it is fine, I can create one and update the various files accordingly (they refer to the other tracking issue now). On the Zulip chat, I believe `@jonas-schievink` volunteered to be a reviewer 💯
2021-02-02Rollup merge of #81455 - Amanieu:aarch64_ilp32, r=sanxiynJack Huey-4/+8
Add AArch64 big-endian and ILP32 targets This PR adds 3 new AArch64 targets: - `aarch64_be-unknown-linux-gnu` - `aarch64-unknown-linux-gnu_ilp32` - `aarch64_be-unknown-linux-gnu_ilp32` It also fixes some ABI issues on big-endian ARM and AArch64.
2021-02-02Avoid a hir access inside get_staticbjorn3-56/+24
2021-02-02Add a new ABI to support cmse_nonsecure_callHugues de Valon-1/+18
This commit adds a new ABI to be selected via `extern "C-cmse-nonsecure-call"` on function pointers in order for the compiler to apply the corresponding cmse_nonsecure_call callsite attribute. For Armv8-M targets supporting TrustZone-M, this will perform a non-secure function call by saving, clearing and calling a non-secure function pointer using the BLXNS instruction. See the page on the unstable book for details. Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-27 10:58:53 +0000