about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm
AgeCommit message (Collapse)AuthorLines
2020-11-23Upgrades the coverage map to Version 4Rich Kadel-114/+161
Changes the coverage map injected into binaries compiled with `-Zinstrument-coverage` to LLVM Coverage Mapping Format, Version 4 (from Version 3). Note, binaries compiled with this version will require LLVM tools from at least LLVM Version 11.
2020-11-23Use Option::map instead of open coding itLingMan-4/+1
2020-11-21Rename prefix_chunk to prefix_chunk_sizebjorn3-1/+1
2020-11-21Remove StructRet arg attrbjorn3-3/+6
It is applied exactly when the return value has an indirect pass mode. Except for InReg on x86 fastcall, arg attrs are now only used for optimization purposes and thus are fine to ignore.
2020-11-21Replace ByVal attribute with on_stack field for Indirectbjorn3-42/+79
This makes it clearer that only PassMode::Indirect allows ByVal
2020-11-21Replace ZExt and SExt flags with ArgExtension enumbjorn3-1/+19
Both flags are mutually exclusive
2020-11-20Never inline naked functionsTomasz Miąsko-3/+9
The `#[naked]` attribute disabled prologue / epilogue emission for the function and it is responsibility of a developer to provide them. The compiler is no position to inline such functions correctly. Disable inlining of naked functions at LLVM and MIR level.
2020-11-18Auto merge of #79106 - tmiasko:inline-hint, r=nagisa,eddybbors-12/+4
Fix setting inline hint based on `InstanceDef::requires_inline` For instances where `InstanceDef::requires_inline` is true, an attempt is made to set an inline hint though a call to the `inline` function. The attempt is ineffective, since all attributes will be usually removed by the second call. Fix the issue by applying the attributes only once, with user provided attributes having a priority when provided. Closes #79108.
2020-11-18Rollup merge of #78361 - DevJPM:master, r=workingjubileeMara Bos-0/+10
Updated the list of white-listed target features for x86 This PR both adds in-source documentation on what to look out for when adding a new (X86) feature set and [adds all that are detectable at run-time in Rust stable as of 1.27.0](https://github.com/rust-lang/stdarch/blob/master/crates/std_detect/src/detect/arch/x86.rs). This should only enable the use of the corresponding LLVM intrinsics. Actual intrinsics need to be added separately in rust-lang/stdarch. It also re-orders the run-time-detect test statements to be more consistent with the actual list of intrinsics whitelisted and removes underscores not present in the actual names (which might be mistaken as being part of the name) The reference for LLVM's feature names used is [this file](https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Support/X86TargetParser.def). This PR was motivated as the compiler end's part for allowing #67329 to be adressed over on rust-lang/stdarch
2020-11-17Rollup merge of #78702 - wesleywiser:self_profile_cgu_sizes, r=Mark-SimulacrumMara Bos-2/+4
[self-profiling] Include the estimated size of each cgu in the profile This is helpful when looking for CGUs where the size estimate isn't a good indicator of compilation time. I verified that moving the profiling timer call doesn't affect the results. Results: <img width="297" alt="Screen Shot 2020-11-03 at 7 25 04 AM" src="https://user-images.githubusercontent.com/831192/97985503-5901d100-1da6-11eb-9f10-f3e399702952.png"> `measureme` doesn't have support for custom arg names yet so `arg0` is the CGU name and `arg1` is the estimated size.
2020-11-17Fix setting inline hint based on `InstanceDef::requires_inline`Tomasz Miąsko-12/+4
For instances where `InstanceDef::requires_inline` is true, an attempt is made to set an inline hint though a call to the `inline` function. The attempt is ineffective, since all attributes will be usually removed by the second call. Fix the issue by applying the attributes only once, with user provided attributes having a priority when provided.
2020-11-16compiler: fold by valueBastian Kauschke-8/+8
2020-11-15Rollup merge of #77802 - jyn514:bootstrap-specific, r=nikomatsakisJonas Schievink-8/+5
Allow making `RUSTC_BOOTSTRAP` conditional on the crate name Motivation: This came up in the [Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208403962) for https://github.com/rust-lang/compiler-team/issues/350. See also https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258; this implements https://github.com/rust-lang/cargo/issues/6627. The goal is for this to eventually allow prohibiting setting `RUSTC_BOOTSTRAP` in build.rs (https://github.com/rust-lang/cargo/issues/7088). ## User-facing changes - `RUSTC_BOOTSTRAP=1` still works; there is no current plan to remove this. - Things like `RUSTC_BOOTSTRAP=0` no longer activate nightly features. In practice this shouldn't be a big deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - `RUSTC_BOOTSTRAP=x` will enable nightly features only for crate `x`. - `RUSTC_BOOTSTRAP=x,y` will enable nightly features only for crates `x` and `y`. ## Implementation changes The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()`, which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build`, a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible, since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` I'm not sure whether this counts as T-compiler or T-lang; _technically_ RUSTC_BOOTSTRAP is an implementation detail, but it's been used so much it seems like this counts as a language change too. r? `@joshtriplett` cc `@Mark-Simulacrum` `@hsivonen`
2020-11-15Rollup merge of #78848 - DevJPM:ci-llvm-9, r=nikicDylan DPC-43/+4
Bump minimal supported LLVM version to 9 This bumps the minimal tested llvm version to 9. This should enable supporting newer LLVM features (and CPU extensions). This was motived by #78361 having to drop features because of LLVM 8 not supporting certain CPU extensions yet. This was declared relatively uncontroversial on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Min.20Supported.20LLVM.20Upgrade.20Process.3F/near/215957859). Paging ````@eddyb```` because there was a comment in the [dockerfile](https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/x86_64-gnu-llvm-8/Dockerfile#L42) describing a hack (which I don't quite understand) which was also blocked by not having LLVM 9.
2020-11-14Auto merge of #78959 - petrochenkov:likeuefi, r=nagisabors-3/+1
rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc` And document what `is_like_windows` and `is_like_msvc` actually mean in more detail. Addresses FIXMEs left from https://github.com/rust-lang/rust/pull/71030. r? `@nagisa`
2020-11-13remove internal simd_size_and_ty from llvm backendAshley Mannix-34/+17
2020-11-12Rollup merge of #78950 - khyperia:spirv-asm, r=AmanieuMara Bos-1/+11
Add asm register information for SPIR-V As discussed in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Defining.20asm!.20for.20new.20architecture), we at [rust-gpu](https://github.com/EmbarkStudios/rust-gpu) would like to support `asm!` for our SPIR-V backend. However, we cannot do so purely without frontend support: [this match](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_target/src/asm/mod.rs#L185) fails and so `asm!` is not supported ([error reported here](https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/compiler/rustc_ast_lowering/src/expr.rs#L1095)). To resolve this, we need to stub out register information for SPIR-V to support getting the `asm!` content all the way to [`AsmBuilderMethods::codegen_inline_asm`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/trait.AsmBuilderMethods.html#tymethod.codegen_inline_asm), at which point the rust-gpu backend can do all the parsing and codegen that is needed. This is a pretty weird PR - adding support for a backend that isn't in-tree feels pretty gross to me, but I don't see an easy way around this. ``@Amanieu`` said I should submit it anyway, so, here we are! Let me know if this needs to go through a more formal process (MCP?) and what I should do to help this along. I based this off the [wasm asm PR](https://github.com/rust-lang/rust/pull/78684), which unfortunately this PR conflicts with that one quite a bit, sorry for any merge conflict pain :( --- Some open questions: - What do we call the register class? Some context, SPIR-V is an SSA-based IR, there are "instructions" that create IDs (referred to as `<id>` in the spec), which can be referenced by other instructions. So, `reg` isn't exactly accurate, they're SSA IDs, not re-assignable registers. - What happens when a SPIR-V register gets to the LLVM backend? Right now it's a `bug!`, but should that be a `sess.fatal()`? I'm not sure if it's even possible to reach that point, maybe there's a check that prevents the `spirv` target from even reaching that codepath.
2020-11-12rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc`Vadim Petrochenkov-3/+1
Document what `is_like_windows` and `is_like_msvc` mean in more detail.
2020-11-12fixed a re-format due to removed chain callDevJPM-5/+1
2020-11-12Dropped Support for Bidirectional Custom Target Definition EmulationDevJPM-12/+0
as requested in the review and argued that this is only consistent with later LLVM upgrades
2020-11-12Removed an unused function now that LLVM 9 is the minimal supported versionDevJPM-5/+0
The function was only used in LLVM 8 compatibility code and was found and flagged by dead code detection and now removed.
2020-11-12fully exploited the dropped support of LLVM 8DevJPM-24/+6
This commit grepped for LLVM_VERSION_GE, LLVM_VERSION_LT, get_major_version and min-llvm-version and statically evaluated every expression possible (and sensible) assuming that the LLVM version is >=9 now
2020-11-11Change capitalization of Spirv to SpirVkhyperia-4/+4
This matches the capitalization of RiscV
2020-11-11Add asm register information for SPIR-Vkhyperia-1/+11
2020-11-10Changed unwrap_or to unwrap_or_else in some places.Nicholas-Baron-6/+8
The discussion seems to have resolved that this lint is a bit "noisy" in that applying it in all places would result in a reduction in readability. A few of the trivial functions (like `Path::new`) are fine to leave outside of closures. The general rule seems to be that anything that is obviously an allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it is a 0-sized allocation.
2020-11-08rustc_target: Rename some target options to avoid tautologyVadim Petrochenkov-5/+5
`target.target_endian` -> `target.endian` `target.target_c_int_width` -> `target.c_int_width` `target.target_os` -> `target.os` `target.target_env` -> `target.env` `target.target_vendor` -> `target.vendor` `target.target_family` -> `target.os_family` `target.target_mcount` -> `target.mcount`
2020-11-08Collapse all uses of `target.options.foo` into `target.foo`Vadim Petrochenkov-53/+40
with an eye on merging `TargetOptions` into `Target`. `TargetOptions` as a separate structure is mostly an implementation detail of `Target` construction, all its fields logically belong to `Target` and available from `Target` through `Deref` impls.
2020-11-08Support repr(simd) on ADTs containing a single array fieldgnzlbg-50/+72
This PR allows using `#[repr(simd)]` on ADTs containing a single array field: ```rust #[repr(simd)] struct S0([f32; 4]); #[repr(simd)] struct S1<const N: usize>([f32; N]); #[repr(simd)] struct S2<T, const N: usize>([T; N]); ``` This should allow experimenting with portable packed SIMD abstractions on nightly that make use of const generics.
2020-11-07Allow making `RUSTC_BOOTSTRAP` conditional on the crate nameJoshua Nelson-8/+5
The main change is that `UnstableOptions::from_environment` now requires an (optional) crate name. If the crate name is unknown (`None`), then the new feature is not available and you still have to use `RUSTC_BOOTSTRAP=1`. In practice this means the feature is only available for `--crate-name`, not for `#![crate_name]`; I'm interested in supporting the second but I'm not sure how. Other major changes: - Added `Session::is_nightly_build()`, which uses the `crate_name` of the session - Added `nightly_options::match_is_nightly_build`, a convenience method for looking up `--crate-name` from CLI arguments. `Session::is_nightly_build()`should be preferred where possible, since it will take into account `#![crate_name]` (I think). - Added `unstable_features` to `rustdoc::RenderOptions` There is a user-facing change here: things like `RUSTC_BOOTSTRAP=0` no longer active nightly features. In practice this shouldn't be a big deal, since `RUSTC_BOOTSTRAP` is the opposite of stable and everyone uses `RUSTC_BOOTSTRAP=1` anyway. - Add tests Check against `Cheat`, not whether nightly features are allowed. Nightly features are always allowed on the nightly channel. - Only call `is_nightly_build()` once within a function - Use booleans consistently for rustc_incremental Sessions can't be passed through threads, so `read_file` couldn't take a session. To be consistent, also take a boolean in `write_file_header`.
2020-11-05Addressed all feedback to dateRich Kadel-5/+3
2020-11-05Injecting expressions in place of counters where helpfulRich Kadel-4/+15
Implementing the Graph traits for the BasicCoverageBlock graph. optimized replacement of counters with expressions plus new BCB graphviz * Avoid adding coverage to unreachable blocks. * Special case for Goto at the end of the body. Make it non-reportable. Improved debugging and formatting options (from env) Don't automatically add counters to BCBs without CoverageSpans. They may still get counters but only if there are dependencies from other BCBs that have spans, I think. Make CodeRegions optional for Counters too. It is possible to inject counters (`llvm.instrprof.increment` intrinsic calls without corresponding code regions in the coverage map. An expression can still uses these counter values. Refactored instrument_coverage.rs -> instrument_coverage/mod.rs, and then broke up the mod into multiple files. Compiling with coverage, with the expression optimization, works on the json5format crate and its dependencies. Refactored debug features from mod.rs to debug.rs
2020-11-05Rust coverage before splitting instrument_coverage.rsRich Kadel-28/+38
2020-11-04Auto merge of #78280 - bugadani:span, r=lcnrbors-14/+14
Codegen: Query span as late as possible
2020-11-04`u128` truncation and sign extension are not just interpreter relatedoli-2/+1
2020-11-04s/Scalar::Raw/Scalar::Intoli-2/+2
2020-11-04Split the "raw integer bytes" part out of `Scalar`Oliver Scherer-4/+4
2020-11-03Rollup merge of #77950 - arlosi:sha256, r=eddybMara Bos-0/+2
Add support for SHA256 source file hashing Adds support for `-Z src-hash-algorithm sha256`, which became available in LLVM 11. Using an older version of LLVM will cause an error `invalid checksum kind` if the hash algorithm is set to sha256. r? `@eddyb` cc #70401 `@est31`
2020-11-03[self-profiling] Include the estimated size of each cgu in the profileWesley Wiser-2/+4
This is helpful when looking for CGUs where the size estimate isn't a good indicator of compilation time. I verified that moving the profiling timer call doesn't affect the results.
2020-11-03Auto merge of #78448 - rylev:cache-foreign_modules, r=wesleywiserbors-2/+2
foreign_modules query hash table lookups When compiling a large monolithic crate we're seeing huge times in the `foreign_modules` query due to repeated iteration over foreign modules (in order to find a module by its id). This implements hash table lookups so that which massively reduces time spent in that query in this particular case. We'll need to see if the overhead of creating the hash table has a negative impact on performance in more normal compilation scenarios. I'm working with `@wesleywiser` on this.
2020-10-31Implement -Z relax-elf-relocations=yes|noAnthony Ramine-1/+5
This lets rustc users tweak whether the linker should relax ELF relocations, namely whether it should emit R_X86_64_GOTPCRELX relocations instead of R_X86_64_GOTPCREL, as the former is allowed by the ABI to be further optimised. The default value is whatever the target defines.
2020-10-30Fix even more clippy warningsJoshua Nelson-22/+15
2020-10-28Auto merge of #78414 - nox:function-sections, r=nagisa,bjorn3bors-1/+2
Implement -Z function-sections=yes|no This lets rustc users tweak whether all functions should be put in their own TEXT section, using whatever default value the target defines if the flag is missing. I'm having fun experimenting with musl libc and trying to implement the start symbol in Rust, that means avoiding code that requires relocations, and AFAIK putting everything in its own section makes the toolchain generate `GOTPCREL` relocations for symbols that could use plain old PC-relative addressing (at least on `x86_64`) if they were all in the same section.
2020-10-27Cache foreign_modules queryRyan Levick-2/+2
2020-10-27Query span as late as possibleDániel Buga-14/+14
2020-10-26Implement -Z function-sections=yes|noAnthony Ramine-1/+2
This lets rustc users tweak whether all functions should be put in their own TEXT section, using whatever default value the target defines if the flag is missing.
2020-10-26Auto merge of #68965 - eddyb:mir-inline-scope, r=nagisa,oli-obkbors-162/+188
rustc_mir: track inlined callees in SourceScopeData. We now record which MIR scopes are the roots of *other* (inlined) functions's scope trees, which allows us to generate the correct debuginfo in codegen, similar to what LLVM inlining generates. This PR makes the `ui` test `backtrace-debuginfo` pass, if the MIR inliner is turned on by default. Also, `#[track_caller]` is now correct in the face of MIR inlining (cc `@anp).` Fixes #76997. r? `@rust-lang/wg-mir-opt`
2020-10-26Updated documentation, x86 feature detection testing, and removed LLVM 9 ↵DevJPM-0/+5
exclusive features Updated the added documentation in llvm_util.rs to note which copies of LLVM need to be inspected. Removed avx512bf16 and avx512vp2intersect because they are unsupported before LLVM 9 with the build with external LLVM 8 being supported Re-introduced detection testing previously removed for un-requestable features tsc and mmx
2020-10-26Rollup merge of #78126 - shepmaster:aarch64-apple-darwin-valist, r=nagisaDylan DPC-10/+8
Properly define va_arg and va_list for aarch64-apple-darwin From [Apple][]: > Because of these changes, the type `va_list` is an alias for `char*`, > and not for the struct type in the generic procedure call standard. With this change `/x.py test --stage 1 src/test/ui/abi/variadic-ffi` passes. Fixes #78092 [Apple]: https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
2020-10-25Properly define va_arg and va_list for aarch64-apple-darwinJake Goulding-2/+2
From [Apple][]: > Because of these changes, the type `va_list` is an alias for `char*`, > and not for the struct type in the generic procedure call standard. With this change `/x.py test --stage 1 src/test/ui/abi/variadic-ffi` passes. Fixes #78092 [Apple]: https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
2020-10-25Updated the list of white-listed target features for x86DevJPM-0/+5
This PR both adds in-source documentation on what to look out for when adding a new (X86) feature set and adds all that are detectable at run-time in Rust stable as of 1.27.0. This should only enable the use of the corresponding LLVM intrinsics. Actual intrinsics need to be added separately in rust-lang/stdarch. It also re-orders the run-time-detect test statements to be more consistent with the actual list of intrinsics whitelisted and removes underscores not present in the actual names (which might be mistaken as being part of the name)
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 05:57:07 +0000