about summary refs log tree commit diff
path: root/src/librustc_codegen_ssa
AgeCommit message (Collapse)AuthorLines
2020-07-31Move from `log` to `tracing`Oliver Scherer-1/+1
2020-07-30Rust function-level coverage now works on external cratesRich Kadel-1/+5
Fixed a known issue in the coverage map where some regions had nonsensical source code locations. External crate functions are already included in their own coverage maps, per library, and don't need to also be added to the importing crate's coverage map. (In fact, their source start and end byte positions are not relevant to the importing crate's SourceMap.) The fix was to simply skip trying to add imported coverage info to the coverage map if the instrumented function is not "local". The injected counters are still relevant, however, and the LLVM `instrprof.increment` intrinsic call parameters will map those counters to the external crates' coverage maps, when generating runtime coverage data.
2020-07-29Auto merge of #74733 - richkadel:llvm-coverage-map-gen-5, r=tmandrybors-213/+355
Fixed coverage map issues; better aligned with LLVM APIs Found some problems with the coverage map encoding when testing with more than one counter per function. While debugging, I realized some better ways to structure the Rust implementation of the coverage mapping generator. I refactored somewhat, resulting in less code overall, expanded coverage of LLVM Coverage Map capabilities, and much closer alignment with LLVM data structures, APIs, and naming. This should be easier to follow and easier to maintain. r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
2020-07-29Moved structs/enums with repr(C) to LLVM types into ffi.rs cratesRich Kadel-64/+70
Some were in librustc_codegen_llvm, but others are not tied to LLVM, so I put them in a new crate: librustc_codegen_ssa/coverageinfo/ffi.rs
2020-07-29Auto merge of #72049 - mati865:mingw-lld, r=petrochenkovbors-4/+23
MinGW: enable dllexport/dllimport Fixes (only when using LLD) https://github.com/rust-lang/rust/issues/50176 Fixes https://github.com/rust-lang/rust/issues/72319 This makes `windows-gnu` on pair with `windows-msvc` when it comes to symbol exporting. For MinGW it means both good things like correctly working dllimport/dllexport, ability to link with LLD and bad things like https://github.com/rust-lang/rust/issues/27438. Not sure but maybe this should land behind unstable compiler option (`-Z`) or environment variable?
2020-07-29MinGW: emit dllexport/dllimport by rustcMateusz Mikuła-4/+23
This fixes various cases where LD could not guess dllexport correctly and greatly improves compatibility with LLD which is not going to support linker scripts anytime soon
2020-07-28FunctionCoverage: improve type checking with newtype_index typesRich Kadel-40/+88
2020-07-28Refactor MIR coverage instrumentationRich Kadel-16/+16
Lays a better foundation for injecting more counters in each function.
2020-07-26Auto merge of #74664 - pnadon:Miri-rename-undef-uninit, r=RalfJungbors-1/+1
Miri rename undef uninit Renamed parts of code within the `librustc_middle/mir/interpret/` directory. Related issue [#71193](https://github.com/rust-lang/rust/issues/71193)
2020-07-25Fixed coverage map issues; better aligned with LLVM APIsRich Kadel-210/+298
Found some problems with the coverage map encoding when testing with more than one counter per function. While debugging, I realized some better ways to structure the Rust implementation of the coverage mapping generator. I refactored somewhat, resulting in less code overall, expanded coverage of LLVM Coverage Map capabilities, and much closer alignment with LLVM data structures, APIs, and naming. This should be easier to follow and easier to maintain.
2020-07-23replace miri_start_panic intrinsic by 'extern fn'Ralf Jung-5/+0
2020-07-22renamed ScalarMaybeUninit::not_undef to check_initPhilippe Nadon-1/+1
Renamed the function ScalarMaybeUninit::not_undef to ScalarMaybeUninit::check_init in the file src/librustc_middle/mir/interpret/value.rs, to reflect changes in terminology used. Related issue rust-lang#71193
2020-07-22Rollup merge of #74643 - petrochenkov:noenvrerun, r=Mark-SimulacrumManish Goregaokar-4/+0
build: Remove unnecessary `cargo:rerun-if-env-changed` annotations ... and a couple of related cleanups. rustc and cargo now track the majority of env var dependencies automatically (https://github.com/rust-lang/cargo/pull/8421), so the annotations are no longer necessary.
2020-07-22Rollup merge of #74631 - petrochenkov:ehdr2, r=jonas-schievinkManish Goregaokar-8/+4
rustc_target: Add a target spec option for disabling `--eh-frame-hdr` Disable `--eh-frame-hdr` for targets that use an `ld`-like linker, but don't support that option. Do it through a target spec option rather than through hard-coding in `linker.rs`. The option is still enabled by default though. cc https://github.com/rust-lang/rust/pull/73564 Fixes https://github.com/rust-lang/rust/pull/73564#issuecomment-657011004 Fixes https://github.com/rust-lang/rust/pull/74625 Fixes https://github.com/rust-embedded/msp430-rt/issues/12
2020-07-22Rollup merge of #73893 - ajpaverd:cfguard-stabilize, r=nikomatsakisManish Goregaokar-1/+1
Stabilize control-flow-guard codegen option This is the stabilization PR discussed in #68793. It converts the `-Z control-flow-guard` debugging option into a codegen option (`-C control-flow-guard`), and changes the associated tests.
2020-07-22build: Remove unnecessary `cargo:rerun-if-env-changed` annotationsVadim Petrochenkov-4/+0
2020-07-22rustc_target: Add a target spec option for disabling `--eh-frame-hdr`Vadim Petrochenkov-8/+4
2020-07-22[AVR] Correctly set the pointer address space when constructing pointers to ↵Dylan McKay-4/+12
functions This patch extends the existing `type_i8p` method so that it requires an explicit address space to be specified. Before this patch, the `type_i8p` method implcitily assumed the default address space, which is not a safe transformation on all targets, namely AVR. The Rust compiler already has support for tracking the "instruction address space" on a per-target basis. This patch extends the code generation routines so that an address space must always be specified. In my estimation, around 15% of the callers of `type_i8p` produced invalid code on AVR due to the loss of address space prior to LLVM final code generation. This would lead to unavoidable assertion errors relating to invalid bitcasts. With this patch, the address space is always either 1) explicitly set to the instruction address space because the logic is dealing with functions which must be placed there, or 2) explicitly set to the default address space 0 because the logic can only operate on data space pointers and thus we keep the existing semantics of assuming the default, "data" address space.
2020-07-20mir: `unused_generic_params` queryDavid Wood-13/+14
This commit implements the `unused_generic_params` query, an initial version of polymorphization which detects when an item does not use generic parameters and is being needlessly monomorphized as a result. Signed-off-by: David Wood <david@davidtw.co>
2020-07-20debuginfo: add type metadata for paramsDavid Wood-2/+5
This commit adds type metadata for generic parameters (that arise from polymorphization). Generic parameter metadata is considered zero-sized and named after the generic parameter. Signed-off-by: David Wood <david@davidtw.co>
2020-07-20mir: avoid double substitutionDavid Wood-2/+1
This commit avoids a natural, free-range double substitution error by monomorphizing the projection element before getting the type. Signed-off-by: David Wood <david@davidtw.co>
2020-07-19Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4, r=tmandrybors-37/+267
Generating the coverage map @tmandry @wesleywiser rustc now generates the coverage map and can support (limited) coverage report generation, at the function level. Example commands to generate a coverage report: ```shell $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE="main.profraw" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main ``` ![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png) r? @wesleywiser Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
2020-07-18Rollup merge of #74478 - rust-lang:revert-74416-linker-locale-utf8, ↵Manish Goregaokar-3/+1
r=Mark-Simulacrum Revert "Use an UTF-8 locale for the linker." Reverts rust-lang/rust#74416 This is suspected to have caused significant compile time regressions: https://perf.rust-lang.org/compare.html?start=39d5a61f2e4e237123837f5162cc275c2fd7e625&end=d3df8512d2c2afc6d2e7d8b5b951dd7f2ad77b02&stat=instructions:u
2020-07-18Revert "Use an UTF-8 locale for the linker."Jonas Schievink-3/+1
2020-07-17Rollup merge of #74464 - FedericoPonzi:fix-#67108, r=ManishearthManish Goregaokar-31/+3
Use pathdiff crate I wanted to tackle a simple issue, and stumbled upon #67108: this pr removes the function which was exported to the external crate as required in the todo/issue. I've tested it with: ``` ./x.py build --stage 1 --keep-stage 1 src/librustc_codegen_ssa ``` And it looks like it's compiling
2020-07-17Run fmtManish Goregaokar-1/+1
2020-07-18fixes #67108 by using the external crateFederico Ponzi-31/+3
2020-07-17Generating the coverage mapRich Kadel-37/+267
rustc now generates the coverage map and can support (limited) coverage report generation, at the function level. Example: $ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu $ $BUILD/stage1/bin/rustc -Zinstrument-coverage \ $HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs $ LLVM_PROFILE_FILE="main.profraw" ./main called $ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata $ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main 1| 1|pub fn will_be_called() { 2| 1| println!("called"); 3| 1|} 4| | 5| 0|pub fn will_not_be_called() { 6| 0| println!("should not have been called"); 7| 0|} 8| | 9| 1|fn main() { 10| 1| let less = 1; 11| 1| let more = 100; 12| 1| 13| 1| if less < more { 14| 1| will_be_called(); 15| 1| } else { 16| 1| will_not_be_called(); 17| 1| } 18| 1|}
2020-07-17Use an UTF-8 locale for the linker.Jakub Kądziołka-1/+3
2020-07-15Auto merge of #74113 - lcnr:type-dependent-consts-2, r=eddybbors-4/+4
Support const args in type dependent paths (Take 2) once more, except it is sound this time :smiling_face_with_three_hearts: previously #71154 ----- ```rust #![feature(const_generics)] struct A; impl A { fn foo<const N: usize>(&self) -> usize { N } } struct B; impl B { fn foo<const N: usize>(&self) -> usize { 42 } } fn main() { let a = A; a.foo::<7>(); } ``` When calling `type_of` for generic const arguments, we now use the `TypeckTables` of the surrounding body to get the expected type. This alone causes cycle errors though, as we now have `typeck_tables_of(main)` -> `...` -> `type_of(main_ANON0 := 7)` -> `typeck_tables_of(main)` :zap: (see https://github.com/rust-lang/rust/issues/68400#issuecomment-611760290) To prevent this we must not call `type_of(const_arg)` during `typeck_tables_of`. This is achieved by calling `type_of(param_def_id)` instead. We have to somehow remember the `DefId` of the param through all of typeck, which is done using the struct `ty::WithOptConstParam<DefId>`, which replaces `DefId` where needed and contains an `Option<DefId>` to be able to store the const parameter in case it exists. Queries which are currently cached on disk are split into two variants: `query_name`(cached) and `query_name_(of|for)_const_arg`(not cached), with `query_name_of_const_arg` taking a pair `(did, param_did): (LocalDefId, DefId)`. For some queries a method `query_name_of_opt_const_arg` is added to `TyCtxt` which takes a `ty::WithOptConstParam` and either calls `query_name` or `query_name_of_const_arg` depending on the value of `const_param_did`. r? @eddyb @varkor
2020-07-15InstanceDef::ItemBastian Kauschke-2/+2
2020-07-15const_eval_resolveBastian Kauschke-1/+1
2020-07-15ConstKind::UnevaluatedBastian Kauschke-2/+2
2020-07-15Undo the `const_str` changes from the previous commit.Nicholas Nethercote-5/+6
2020-07-15Change `SymbolName::name` to a `&str`.Nicholas Nethercote-16/+14
This eliminates a bunch of `Symbol::intern()` and `Symbol::as_str()` calls, which is good, because they require locking the interner. Note that the unsafety in `from_cycle_error()` is identical to the unsafety on other adjacent impls.
2020-07-15Add and use more static symbols.Nicholas Nethercote-23/+22
Note that the output of `unpretty-debug.stdout` has changed. In that test the hash values are normalized from a symbol numbers to small numbers like "0#0" and "0#1". The increase in the number of static symbols must have caused the original numbers to contain more digits, resulting in different pretty-printing prior to normalization.
2020-07-14Stabilize control-flow-guard codegen optionAndrew Paverd-1/+1
2020-07-11Rollup merge of #74167 - jclulow:illumos-linker-eh-frame-hdr-fix, r=petrochenkovManish Goregaokar-1/+1
linker: illumos ld does not support --eh-frame-hdr As of rust-lang/rust#73564, the --eh-frame-hdr flag is unconditionally passed to linkers on many platforms. The illumos link editor does not currently support this flag. The linker machinery in the Rust toolchain currently seems to use the (potentially cross-compiled) target to choose linker flags, rather than looking at what might be running on the build system. Disabling the flag for all illumos/Solaris targets seems like the best we can do for now without more serious surgery.
2020-07-11Rollup merge of #73715 - MaulingMonkey:pr-natvis-tuples, r=AmanieuManish Goregaokar-2/+12
debuginfo: Mangle tuples to be natvis friendly, typedef basic types These changes are meant to unblock rust-lang/rust#70052 "Update hashbrown to 0.8.0" by allowing the use of `tuple<u64, u64>` as a .natvis expression in MSVC style debuggers (MSVC, WinDbg, CDB, etc.) * f8eb81b does the actual mangling of `(u64, u64)` -> `tuple<u64, 64>` * 24a728a allows `u64` to resolve (fixing `$T1` / `$T2` when used to visualize `HashMap<u64, u64, ...>`)
2020-07-10Rollup merge of #74127 - tamird:allowlist, r=oli-obkManish Goregaokar-7/+6
Avoid "whitelist" Other terms are more inclusive and precise.
2020-07-10Rollup merge of #74103 - ajpaverd:cfguard-msvc-only, r=nikomatsakisManish Goregaokar-12/+4
Only add CFGuard on `windows-msvc` targets As @ollie27 pointed out in #73893, the `cfguard` module flag causes incorrect behavior on `windows-gnu` targets. This patch restricts rustc to only add this flag for `windows-msvc` targets (this may need to be changed if other linkers gain support for CFGuard).
2020-07-10Avoid "whitelist"Tamir Duberstein-7/+6
Other terms are more inclusive and precise.
2020-07-10Only add cfguard module flag on windows-msvcAndrew Paverd-12/+4
2020-07-08linker: illumos ld does not support --eh-frame-hdrJoshua M. Clulow-1/+1
As of rust-lang/rust#73564, the --eh-frame-hdr flag is unconditionally passed to linkers on many platforms. The illumos link editor does not currently support this flag. The linker machinery in the Rust toolchain currently seems to use the (potentially cross-compiled) target to choose linker flags, rather than looking at what might be running on the build system. Disabling the flag for all illumos/Solaris targets seems like the best we can do for now without more serious surgery.
2020-07-05Use for<'tcx> fn pointers in Providers, instead of having Providers<'tcx>.Eduard-Mihai Burtescu-9/+9
2020-07-02Rollup merge of #73724 - CryZe:wasm-saturating-casts, r=alexcrichtonManish Goregaokar-3/+10
Use WASM's saturating casts if they are available WebAssembly supports saturating floating point to integer casts behind a target feature. The feature is already available on many browsers. Beginning with 1.45 Rust will start defining the behavior of floating point to integer casts to be saturating as well. For this Rust constructs additional checks on top of the `fptoui` / `fptosi` instructions it emits. Here we introduce the possibility for the codegen backend to construct saturating casts itself and only fall back to constructing the checks ourselves if that is not possible. Resolves part of #73591
2020-07-02Use WASM's saturating casts if they are availableChristopher Serr-3/+10
WebAssembly supports saturating floating point to integer casts behind a target feature. The feature is already available on many browsers. Beginning with 1.45 Rust will start defining the behavior of floating point to integer casts to be saturating as well. For this Rust constructs additional checks on top of the `fptoui` / `fptosi` instructions it emits. Here we introduce the possibility for the codegen backend to construct saturating casts itself and only fall back to constructing the checks ourselves if that is not possible.
2020-07-02Rollup merge of #73684 - richkadel:llvm-coverage-map-gen-2, r=wesleywiserManish Goregaokar-1/+152
add spans to injected coverage counters, extract with CoverageData query This is the next iteration on the Rust Coverage implementation, and follows PR #73488 @tmandry @wesleywiser I came up with an approach for coverage spans, pushing them through the Call terminator as additional args so they can be extracted by the CoverageData query. I'm using an IndexVec to store them in CoverageData such that there can be only one per index (even if parts of the MIR get duplicated during optimization). If this approach works for you, I can quickly expand on this to build a separate IndexVec for counter expressions, using a separate call that will be ignored during code generation, but from which I can extract the counter expression values. Let me know your thoughts. Thanks! r? @tmandry Rust compiler MCP rust-lang/compiler-team#278 Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
2020-07-02Rollup merge of #73564 - petrochenkov:ehdr, r=AmanieuManish Goregaokar-0/+17
linker: Create GNU_EH_FRAME header by default when producing ELFs Do it in a centralized way in `link.rs` instead of individual target specs. The opt-out is `-Clink-arg=(-Wl,)--no-eh-frame-hdr` if necessary. Fixes https://github.com/rust-lang/rust/issues/73451 cc https://github.com/rust-lang/rust/pull/73483
2020-06-29add spans to injected coverage countersRich Kadel-1/+152
added regions with counter expressions and counters. Added codegen_llvm/coverageinfo mod for upcoming coverage map Move coverage region collection to CodegenCx finalization Moved from `query coverageinfo` (renamed from `query coverage_data`), as discussed in the PR at: https://github.com/rust-lang/rust/pull/73684#issuecomment-649882503 Address merge conflict in MIR instrument_coverage test The MIR test output format changed for int types. moved debug messages out of block.rs This makes the block.rs calls to add coverage mapping data to the CodegenCx much more concise and readable. move coverage intrinsic handling into llvm impl I realized that having half of the coverage intrinsic handling in `rustc_codegen_ssa` and half in `rustc_codegen_llvm` meant that any non-llvm backend would be bound to the same decisions about how the coverage-related MIR terminators should be handled. To fix this, I moved the non-codegen portion of coverage intrinsic handling into its own trait, and implemented it in `rustc_codegen_llvm` alongside `codegen_intrinsic_call`. I also added the (required?) stubs for the new intrinsics to `IntrepretCx::emulate_intrinsic()`, to ensure calls to this function do not fail if called with these new but known intrinsics. address PR Feedback on 28 June 2020 2:48pm PDT
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 18:33:34 +0000