about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src
AgeCommit message (Collapse)AuthorLines
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 #82057 - upsuper-forks:cstr, r=davidtwco,wesleywiserDylan DPC-29/+29
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-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-14Replace const_cstr with cstr crateXidorn Quan-29/+29
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>
2021-01-29Rollup merge of #79570 - alexcrichton:split-debuginfo, r=bjorn3Yuki Okushi-25/+27
rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo` This commit adds a new stable codegen option to rustc, `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files, meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361, but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default, but that's a problem left to get tackled another day. Closes #79361
2021-01-28rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`Alex Crichton-25/+27
This commit adds a new stable codegen option to rustc, `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files, meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361, but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default, but that's a problem left to get tackled another day. Closes #79361
2021-01-28Rollup merge of #79951 - LeSeulArtichaut:ty-ir, r=nikomatsakisYuki Okushi-39/+36
Refractor a few more types to `rustc_type_ir` In the continuation of #79169, ~~blocked on that PR~~. This PR: - moves `IntVarValue`, `FloatVarValue`, `InferTy` (and friends) and `Variance` - creates the `IntTy`, `UintTy` and `FloatTy` enums in `rustc_type_ir`, based on their `ast` and `chalk_ir` equilavents, and uses them for types in the rest of the compiler. ~~I will split up that commit to make this easier to review and to have a better commit history.~~ EDIT: done, I split the PR in commits of 200-ish lines each r? `````@nikomatsakis````` cc `````@jackh726`````
2021-01-27Add big-endian support for AArch64 va_argAmanieu d'Antras-4/+8
2021-01-24Auto merge of #80838 - nagisa:nagisa/stack-probe-type, r=cuviperbors-19/+26
Target stack-probe support configurable finely This adds capability to configure the target's stack probe support in a more precise manner than just on/off. In particular now we allow choosing between always inline-asm, always call or either one of those depending on the LLVM version. Note that this removes the ability to turn off the generation of the stack-probe attribute. This is valid to replace it with inline-asm for all targets because `probe-stack="inline-asm"` will not generate any machine code on targets that do not currently support stack probes. This makes support for stack probes on targets that don't have any right now automatic with LLVM upgrades in the future. (This is valid to do based on the fact that clang unconditionally sets this attribute when `-fstack-clash-protection` is used, AFAICT) cc #77885 r? `@cuviper`
2021-01-23Make declare_cfn more flexibleCaleb Zulawski-16/+29
2021-01-18Use ty::{IntTy,UintTy,FloatTy} in rustcLeSeulArtichaut-39/+36
2021-01-17Rollup merge of #81095 - LingMan:unwrap, r=oli-obkMara Bos-5/+1
Use Option::unwrap_or instead of open-coding it r? ```@oli-obk``` Noticed this while we were talking about the other PR just now 😆 ```@rustbot``` modify labels +C-cleanup +T-compiler
2021-01-16Use Option::unwrap_or instead of open-coding itLingMan-5/+1
2021-01-16Use Option::map instead of open-coding itLingMan-4/+2
2021-01-16Target stack-probe support configurable finelySimonas Kazlauskas-19/+26
This adds capability to configure the target's stack probe support in a more precise manner than just on/off. In particular now we allow choosing between always inline-asm, always call or either one of those depending on the LLVM version on a per-target basis.
2021-01-16Auto merge of #77885 - erikdesjardins:probeasm, r=cuviperbors-9/+16
Use probe-stack=inline-asm in LLVM 11+ Fixes (?) #74405, related to #43241 r? `@cuviper`
2021-01-15Rollup merge of #81008 - tmiasko:generator-layout-err, r=tmandryYuki Okushi-2/+3
Don't ICE when computing a layout of a generator tainted by errors Fixes #80998.
2021-01-15Rollup merge of #80944 - LingMan:map_or, r=nagisaYuki Okushi-2/+1
Use Option::map_or instead of `.map(..).unwrap_or(..)` ``@rustbot`` modify labels +C-cleanup +T-compiler
2021-01-14Use probe-stack=inline-asm in LLVM 11+Erik Desjardins-9/+16
2021-01-14Use Option::map_or instead of `.map(..).unwrap_or(..)`LingMan-2/+1
2021-01-14Don't ICE when computing a layout of a generator tainted by errorsTomasz Miąsko-2/+3
2021-01-13Remove the unused context from CreateDebugLocationJosh Stone-2/+0
This went unused in commit 88d874de6395, part of #68965.
2021-01-12Auto merge of #80499 - matthiaskrgr:red_clos, r=estebankbors-1/+1
remove redundant closures (clippy::redundant_closure)
2021-01-09Auto merge of #80749 - as-com:target-cpu-actually-native, r=nagisabors-2/+38
Make target-cpu=native detect individual features This PR makes target-cpu=native check for and enable/disable individual features instead of detecting and targeting a CPU by name. This brings the flag's behavior more in line with clang and gcc and ensures that the host actually supports each feature that we are compiling for. This should resolve issues with miscompilations on e.g. "Haswell" Pentiums and Celerons that lack support for AVX, and also enable support for `aes` on Broadwell processors that support it. It should also resolve issues with failing to detect feature support in newer CPUs that aren't yet known by LLVM (see: #80633). Fixes #54688 Fixes #48464 Fixes #38218
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-27 13:00:22 +0000