| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Multi-variant layouts for generators
This allows generators to overlap fields using variants, but doesn't do any such overlapping yet. It creates one variant for every state of the generator (unresumed, returned, panicked, plus one for every yield), and puts every stored local in each of the yield-point variants.
Required for optimizing generator layouts (#52924).
There was quite a lot of refactoring needed for this change. I've done my best in later commits to eliminate assumptions in the code that only certain kinds of types are multi-variant, and to centralize knowledge of the inner mechanics of generators in as few places as possible.
This change also emits debuginfo about the fields contained in each variant, as well as preserving debuginfo about stored locals while running in the generator.
Also, fixes #59972.
Future work:
- Use this change for an optimization pass that actually overlaps locals within the generator struct (#52924)
- In the type layout fields, don't include locals that are uninitialized for a particular variant, so miri and UB sanitizers can check our memory (see https://github.com/rust-lang/rust/issues/59972#issuecomment-483058172)
- Preserve debuginfo scopes across generator yield points
|
|
|
|
|
|
|
|
Avoid repeated interning of static strings.
`file_metadata_raw` interns the strings `"<unknown>"` and `""` very
frequently. This commit avoids that, which reduces the number of symbols
interned significantly and reduces instruction counts by up to 0.5% on
some workloads.
|
|
`file_metadata_raw` interns the strings `"<unknown>"` and `""` very
frequently. This commit avoids that, which reduces the number of symbols
interned significantly and reduces instruction counts by up to 0.5% on
some workloads.
|
|
This commit separates metadata encoding (`tcx.encode_metadata`) from the
creation of the metadata module (which is now handled by
`write_compressed_metadata`, formerly `write_metadata`).
The metadata encoding now occurs slightly earlier in the pipeline, at
the very start of code generation within `start_codegen`.
Metadata *writing* still occurs near the end of compilation; that will
be moved forward in subsequent commits.
|
|
In JSON output, emit a directive after metadata is generated.
To implement pipelining, Cargo needs to know when metadata generation is
finished. This is done via a new JSON "directive".
Unfortunately, metadata file writing currently occurs very late during
compilation, so pipelining won't produce a speed-up. Moving metadata
file writing earlier will be a follow-up.
r? @alexcrichton
|
|
To implement pipelining, Cargo needs to know when metadata generation is
finished. This commit adds code to do that. Unfortunately, metadata file
writing currently occurs very late during compilation, so pipelining
won't produce a speed-up. Moving metadata file writing earlier will be a
follow-up.
The change involves splitting the existing `Emitter::emit` method in
two: `Emitter::emit_diagnostic` and `Emitter::emit_directive`.
The JSON directives look like this:
```
{"directive":"metadata file written: liba.rmeta"}
```
The functionality is behind the `-Z emit-directives` option, and also
requires `--error-format=json`.
|
|
|
|
|
|
|
|
|
|
|
|
This allows generators to overlap fields using variants.
|
|
Future-proof MIR for dedicated debuginfo.
This is #56231 without the last commit (the one that actually moves to `VarDebuginfo`).
Nothing should be broken, but it should no longer depend on debuginfo for anything else.
r? @nikomatsakis
|
|
debuginfo_upvar_ops_sequence.
|
|
Add f16c target_feature
This is requires for Intel 16-bit half-precision float intrinsics: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=fp16&expand=1769 - see companion stdsimd PR: https://github.com/rust-lang-nursery/stdsimd/pull/737.
LLVM, Wikipedia CPUID page, and the Intel Dev Manual all call this CPUID feature "F16C", but the Intel intrinsics guide calls this "FP16C" - this is probably a bug in the intrinsics guide which we are tracking here: https://github.com/rust-lang-nursery/stdsimd/issues/738
r? @alexcrichton
|
|
|
|
|
|
Add `TyCtxt::is_mutable_static`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use -mergefunc-use-aliases for any LLVM >= 8
This functionality is not specific to Rust's LLVM, but any starting in LLVM 8.0,
as noted in <https://github.com/rust-lang/rust/pull/56358#discussion_r237702197>.
cc @nikic
r? @rkruppe
|
|
whitelist RTM x86 target cpu feature
This PR adds support for intels restricted transactional memory cpu feature. I mostly copied what was done for the [movbe](https://github.com/rust-lang/rust/pull/57999) feature.
https://github.com/rust-lang-nursery/stdsimd/issues/718
|
|
|
|
|
|
|
|
|
|
|
|
Clean up handling of `-Z pgo-gen` commandline option.
This PR adapts the `-Z pgo-gen` flag to how Clang and GCC handle the corresponding `-fprofile-generate` flag. In particular, the flag now optionally takes a directory to place the profiling data in and allows to omit the argument (instead of having to pass an empty string).
|
|
Exclude profiler-generated symbols from MSVC __imp_-symbol workaround.
LLVM's profiling instrumentation adds a few symbols that are used by the profiler runtime. Since these show up as globals in the LLVM IR, the compiler generates `dllimport`-related `__imp_` stubs for them. This can lead to linker errors because the instrumentation symbols have weak linkage or are in a comdat section, but the `__imp_` stubs aren't.
Instead of trying to replicate the linkage/comdat setup for the stubs, this PR just excludes the profiler-related symbols from stub-generation since they aren't supposed to be referenced via `__declspec(dllimport)` anywhere anyway.
r? @alexcrichton
EDIT: I considered making this more general, i.e. inferring from the symbol name if it is a Rust symbol or not. But then I figured out that that would yield false negatives for `#[no_mangle]` et al, so I went with a blacklist approach.
|
|
Related to #58372
Related to #58967
|
|
We relax the assumption that the discriminant is always field 0, in
preparations for layouts like generators where this is not going to be
the case.
|
|
|
|
|
|
|
|
More restrictive 2 phase borrows - take 2
Signal lint diagnostic `mutable_borrow_reservation_conflict` when borrow-check finds a 2-phase borrow's reservation overlapping with a shared borrow.
(pnkfelix updated description)
cc #56254 , #59159
blocks PR #59114
r? @pnkfelix
cc @RalfJung @nikomatsakis
|
|
rustc: Start implementing compat with LLVM 9
This commit doesn't actually migrate to LLVM 9, but it brings our own
C++ bindings in line with LLVM 9 and able to compile against tip of
tree. The changes made were:
* The `MainSubprogram` flag for debuginfo moved between flag types.
* Iteration of archive members was tweaked slightly and we have to
construct the two iterators before constructing the returned
`RustArchiveIterator` value.
* The `getOrInsertFunction` binding now returns a wrapper which we use
`getCallee()` on to get the value we're interested in.
|
|
Show better errors for LLVM IR output
I was trying to output LLVM IR directly to the console:
$ rustc hello.rs --emit=llvm-ir -o /dev/stdout
LLVM ERROR: IO failure on output stream: Bad file descriptor
Now `LLVMRustPrintModule` returns an error, and we print:
error: failed to write LLVM IR to /dev/stdout.hello.7rcbfp3g-cgu.0.rcgu.ll: Permission denied
... which is more informative.
|
|
I was trying to output LLVM IR directly to the console:
$ rustc hello.rs --emit=llvm-ir -o /dev/stdout
LLVM ERROR: IO failure on output stream: Bad file descriptor
Now `LLVMRustPrintModule` returns an error, and we print:
error: failed to write LLVM IR to /dev/stdout.hello.7rcbfp3g-cgu.0.rcgu.ll: Permission denied
... which is more informative.
|
|
This commit doesn't actually migrate to LLVM 9, but it brings our own
C++ bindings in line with LLVM 9 and able to compile against tip of
tree. The changes made were:
* The `MainSubprogram` flag for debuginfo moved between flag types.
* Iteration of archive members was tweaked slightly and we have to
construct the two iterators before constructing the returned
`RustArchiveIterator` value.
* The `getOrInsertFunction` binding now returns a wrapper which we use
`getCallee()` on to get the value we're interested in.
|
|
|
|
|
|
Fix stack overflow when generating debuginfo for 'recursive' type
By using 'impl trait', it's possible to create a self-referential
type as follows:
fn foo() -> impl Copy { foo }
This is a function which returns itself.
Normally, the signature of this function would be impossible
to write - it would look like 'fn foo() -> fn() -> fn() ...'
e.g. a function which returns a function, which returns a function...
Using 'impl trait' allows us to avoid writing this infinitely long
type. While it's useless for practical purposes, it does compile and run
However, issues arise when we try to generate llvm debuginfo for such a
type. All 'impl trait' types (e.g. ty::Opaque) are resolved when we
generate debuginfo, which can lead to us recursing back to the original
'fn' type when we try to process its return type.
To resolve this, I've modified debuginfo generation to account for these
kinds of weird types. Unfortunately, there's no 'correct' debuginfo that
we can generate - 'impl trait' does not exist in debuginfo, and this
kind of recursive type is impossible to directly represent.
To ensure that we emit *something*, this commit emits dummy
debuginfo/type names whenever it encounters a self-reference. In
practice, this should never happen - it's just to ensure that we can
emit some kind of debuginfo, even if it's not particularly meaningful
Fixes #58463
|
