summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm
AgeCommit message (Collapse)AuthorLines
2020-12-17Revert "cg_llvm: `fewer_names` in `uncached_llvm_type`"David Wood-9/+1
This reverts commit fa01ce802f1b403a2140fd945b43af86ec3998a1.
2020-12-16cg_llvm: split dwarf filename and comp dirDavid Wood-7/+9
llvm-dwp concatenates `DW_AT_comp_dir` with `DW_AT_GNU_dwo_name` (only when `DW_AT_comp_dir` exists), which can result in it failing to find the DWARF object files. In earlier testing, `DW_AT_comp_dir` wasn't present in the final object and the current directory was the output directory. When running tests through compiletest, the working directory of the compilation is different from output directory and that resulted in `DW_AT_comp_dir` being in the object file (and set to the current working directory, rather than the output directory), and `DW_AT_GNU_dwo_name` being set to the full path (rather than just the filename), so llvm-dwp was failing. This commit changes the compilation directory provided to LLVM to match the output directory, where DWARF objects are output; and ensures that only the filename is used for `DW_AT_GNU_dwo_name`. Signed-off-by: David Wood <david@davidtw.co>
2020-12-16cg_llvm: implement split dwarf supportDavid Wood-30/+87
This commit implements Split DWARF support, wiring up the flag (added in earlier commits) to the modified FFI wrapper (also from earlier commits). Signed-off-by: David Wood <david@davidtw.co>
2020-12-16cg_ssa: introduce `TargetMachineFactoryFn` aliasDavid Wood-7/+10
This commit removes the `TargetMachineFactory` struct and adds a `TargetMachineFactoryFn` type alias which is used everywhere that the previous, long type was used. Signed-off-by: David Wood <david@davidtw.co>
2020-12-16llvm: update ffi bindings for split dwarfDavid Wood-1/+16
This commit modifies the FFI bindings to LLVM required for Split DWARF support in rustc. In particular: - `addPassesToEmitFile`'s wrapper, `LLVMRustWriteOutputFile` now takes a `DwoPath` `const char*`. When disabled, `nullptr` should be provided which will preserve existing behaviour. When enabled, the path to the `.dwo` file should be provided. - `createCompileUnit`'s wrapper, `LLVMRustDIBuilderCreateCompileUnit` now has two additional arguments, for the `DWOId` and to enable `SplitDebugInlining`. `DWOId` should always be zero. - `createTargetMachine`'s wrapper, `LLVMRustCreateTargetMachine` has an additional argument which should be provided the path to the `.dwo` when enabled. Signed-off-by: David Wood <david@davidtw.co>
2020-12-15Auto merge of #73210 - wesleywiser:consts_in_debuginfo, r=oli-obkbors-2/+3
[mir-opt] Allow debuginfo to be generated for a constant or a Place Prior to this commit, debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed, we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.
2020-12-11use strip_prefix over slicing (clippy::manual_strip)Matthias Krüger-2/+2
2020-12-07Fixes to Rust coverageRich Kadel-1/+1
Fixes: #79725 Some macros can create a situation where `fn_sig_span` and `body_span` map to different files. New documentation on coverage tests incorrectly assumed multiple test binaries could just be listed at the end of the `llvm-cov` command, but it turns out each binary needs a `--object` prefix. This PR fixes the bug and updates the documentation to correct that issue. It also fixes a few other minor issues in internal implementation comments, and adds documentation on getting coverage results for doc tests.
2020-12-06[mir-opt] Allow debuginfo to be generated for a constant or a PlaceWesley Wiser-2/+3
Prior to this commit, debuginfo was always generated by mapping a name to a Place. This has the side-effect that `SimplifyLocals` cannot remove locals that are only used for debuginfo because their other uses have been const-propagated. To allow these locals to be removed, we now allow debuginfo to point to a constant value. The `ConstProp` pass detects when debuginfo points to a local with a known constant value and replaces it with the value. This allows the later `SimplifyLocals` pass to remove the local.
2020-12-03Addressed feedback from 2020-12-01Rich Kadel-0/+19
Added one more test (two files) showing coverage of generics and unused functions across crates. Created and referenced new Issues, as requested. Added comments. Added a note about the possible effects of compiler options on LLVM coverage maps.
2020-12-03Combination of commitsRich Kadel-10/+148
Fixes multiple issue with counters, with simplification Includes a change to the implicit else span in ast_lowering, so coverage of the implicit else no longer spans the `then` block. Adds coverage for unused closures and async function bodies. Fixes: #78542 Adding unreachable regions for known MIR missing from coverage map Cleaned up PR commits, and removed link-dead-code requirement and tests Coverage no longer depends on Issue #76038 (`-C link-dead-code` is no longer needed or enforced, so MSVC can use the same tests as Linux and MacOS now) Restrict adding unreachable regions to covered files Improved the code that adds coverage for uncalled functions (with MIR but not-codegenned) to avoid generating coverage in files not already included in the files with covered functions. Resolved last known issue requiring --emit llvm-ir workaround Fixed bugs in how unreachable code spans were added.
2020-12-01Auto merge of #78684 - devsnek:inline-asm-wasm, r=Amanieubors-0/+4
Add wasm32 support to inline asm There is some contention around inline asm and wasm, and I really only made this to figure out the process of hacking on rustc, but I figured as long as the code existed, it was worth uploading. cc `@Amanieu`
2020-12-01Add wasm32 support to inline asmGus Caplan-0/+4
2020-11-29Auto merge of #78863 - KodrAus:feat/simd-array, r=oli-obkbors-50/+55
Support repr(simd) on ADTs containing a single array field This is a squash and rebase of `@gnzlbg's` #63531 I've never actually written code in the compiler before so just fumbled my way around until it would build 😅 I imagine there'll be some work we need to do in `rustc_codegen_cranelift` too for this now, but might need some input from `@bjorn3` to know what that is. cc `@rust-lang/project-portable-simd` ----- 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-26Rollup merge of #79365 - richkadel:llvm-cov-map-version-4, r=wesleywiserJonas Schievink-125/+176
Upgrades the coverage map to Version 4 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. r? ``@wesleywiser``
2020-11-25Update compiler/rustc_codegen_llvm/src/coverageinfo/mapgen.rsRich Kadel-1/+1
2020-11-25replace assert with condition and `fatal` errorRich Kadel-1/+3
2020-11-25Improved version checkRich Kadel-7/+9
2020-11-24Apply suggestions from code reviewRich Kadel-1/+1
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
2020-11-24Check for LLVM 11+ when using `-Z instrument-coverage`Rich Kadel-2/+2
* `rustc` should now compile under LLVM 9 or 10 * Compiler generates an error if `-Z instrument-coverage` is specified but LLVM version is less than 11 * Coverage tests that require `-Z instrument-coverage` and run codegen should be skipped if LLVM version is less than 11
2020-11-23Updated links to LLVM 11 docs and typesRich Kadel-6/+6
2020-11-24Allow disabling TrapUnreachable via -Ztrap-unreachable=noDario Nieuwenhuis-1/+2
This is useful for embedded targets where small code size is desired. For example, on my project (thumbv7em-none-eabi) this yields a 0.6% code size reduction.
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 09:11:30 +0000