| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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.
|
|
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
|
|
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
|
|
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?
|
|
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
|
|
Lays a better foundation for injecting more counters in each function.
|
|
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.
|
|
polymorphize GlobalAlloc::Function
this sadly does not change #74614
r? @eddyb
|
|
Improve codegen for unchecked float casts on wasm
This commit improves codegen for unchecked casts on WebAssembly targets
to use the singluar `iNN.trunc_fMM_{u,s}` instructions. Previously rustc
would codegen a bare `fptosi` and `fptoui` for float casts but for
WebAssembly targets the codegen for these instructions is quite large.
This large codegen is due to the fact that LLVM can speculate these
instructions so the trapping behavior of WebAssembly needs to be
protected against in case they're speculated.
The change here is to update the codegen for the unchecked cast
intrinsics to have a wasm-specific case where they call the appropriate
LLVM intrinsic to generate the right wasm instruction. The intrinsic is
explicitly opting-in to undefined behavior so a trap here for
out-of-bounds inputs on wasm should be acceptable.
cc #73591
|
|
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.
|
|
This commit improves codegen for unchecked casts on WebAssembly targets
to use the singluar `iNN.trunc_fMM_{u,s}` instructions. Previously rustc
would codegen a bare `fptosi` and `fptoui` for float casts but for
WebAssembly targets the codegen for these instructions is quite large.
This large codegen is due to the fact that LLVM can speculate these
instructions so the trapping behavior of WebAssembly needs to be
protected against in case they're speculated.
The change here is to update the codegen for the unchecked cast
intrinsics to have a wasm-specific case where they call the appropriate
LLVM intrinsic to generate the right wasm instruction. The intrinsic is
explicitly opting-in to undefined behavior so a trap here for
out-of-bounds inputs on wasm should be acceptable.
cc #73591
|
|
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.
|
|
va_args implementation for AAPCS.
Implement the va args in codegen for AAPCS, this will be used as the
default va_args implementation for AArch64 rather than the va_args
llvm-ir as it currently is.
This should fix the following issues:
https://github.com/rust-lang/rust/issues/56475
https://github.com/rust-lang/rust/issues/72579
|
|
|
|
|
|
with the correct space
Before this patch, a function pointer stored within an aggregate like a
struct or an enum would always have the default address space `0`.
This patch removes this assumption and instead, introspects the inner
type being pointed at, storing the target address space in the PointeeInfo
struct so that downstream users may query it.
|
|
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.
|
|
Also the alignment should only be done on general register types as
per the AAPCS so fixed that issue.
Copyright (c) 2020, Arm Limited.
|
|
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>
|
|
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>
|
|
This commit skips generating debuginfo type metadata if substitutions
are required by the type. This avoids ICEs that result from layouts
of types with substitutions being computed.
Signed-off-by: David Wood <david@davidtw.co>
|
|
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|}
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
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, ...>`)
|
|
Avoid "whitelist"
Other terms are more inclusive and precise.
|
|
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).
|
|
Other terms are more inclusive and precise.
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
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.
|
|
Implement the va args in codegen for AAPCS, this will be used as the
default va_args implementation for AArch64 rather than the va_args
llvm-ir as it currently is.
Copyright (c) 2020, Arm Limited.
|
|
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
|
|
Prepare for LLVM 11
These are just the code changes needed to build with the current LLVM master (version 11).
r? @nikic
|
|
Fix handling of reserved registers for ARM inline asm
`r6` is now disallowed as an operand since LLVM sometimes uses it as a base pointer.
The check against using the frame pointer as an operand now takes the platform into account and will block either `r7` or `r11` as appropriate.
Fixes #73450
cc @cbiffle
|
|
Omit DW_AT_linkage_name when it is the same as DW_AT_name
The DWARF standard suggests that it might be useful to include
`DW_AT_linkage_name` when it is *distinct* from the identifier name.
Fixes #46487.
Fixes #59422.
|
|
|
|
Emit line info for generator variants
Debuggers should be able to read a generator / async fn state machine and show the line it's suspended at. Eventually, this could grow into an "async stack trace" feature of sorts. While no debugger support this for Rust today, this PR adds the debuginfo necessary for that support to exist.
[This gist](https://gist.github.com/tmandry/6d7004fa008684f76809208847459f9b) shows the resulting debuginfo for a simple example. Here's a snippet:
```
0x00000986: DW_TAG_variant
DW_AT_discr_value (0x03)
0x00000988: DW_TAG_member
DW_AT_name ("3")
DW_AT_type (0x000009bc "Suspend0")
DW_AT_decl_file ("/home/tmandry/code/playground/generator-simple.rs")
DW_AT_decl_line (6)
DW_AT_alignment (8)
DW_AT_data_member_location (0x00)
```
The file and line have been added here. The line currently points to the beginning of the statement containing the yield (or await), because that's what the MIR source info points to for the yield terminator. (We may want to point to the yield or await line specifically, but that can be done independently of this change.)
Debuggers don't know how to use this kind of info yet. However, we're hoping to experiment with adding such support to Fuchsia's debugger. It would be exciting if someone were interested in adding similar to support to gdb/lldb.
r? @oli-obk
cc @eddyb @jonas-schievink
Part of #73524.
|
|
Add unstable `core::mem::variant_count` intrinsic
Adds a new `const fn` intrinsic which can be used to determine the number of variants in an `enum`.
I've shown this to a couple of people and they invariably ask 'why on earth?', but there's actually a very neat use case:
At the moment, if you want to create an opaque array type that's indexed by an `enum` with one element for each variant, you either have to hard-code the number of variants, add a `LENGTH` variant or use a `Vec`, none of which are suitable in general (number of variants could change; pattern matching `LENGTH` becomes frustrating; might not have `alloc`). By including this intrinsic, it becomes possible to write the following:
```rust
#[derive(Copy, Clone)]
enum OpaqueIndex {
A = 0,
B,
C,
}
struct OpaqueVec<T>(Box<[T; std::mem::num_variants::<OpaqueIndex>()]>);
impl<T> std::ops::Index<OpaqueIndex> for OpaqueVec<T> {
type Output = T;
fn index(&self, idx: OpaqueIndex) -> &Self::Output {
&self.0[idx as usize]
}
}
```
(We even have a use cases for this in `rustc` and I plan to use it to re-implement the lang-items table.)
|
|
PDB debug information doesn't appear to be emitted for basic types.
By defining u32 as a typedef for unsigned __int32 when targeting MSVC,
we allow CDB and other debuggers to recognize "u32" as a type/expression.
This in turn unblocks rust-lang#70052 "Update hashbrown to 0.8.0" by
allowing $T1 ..= $T3 to resolve, which would otherwise fail to resolve
when builtin types fail to parse.
|
|
..which doesn't use variant types.
|
|
|
