| Age | Commit message (Collapse) | Author | Lines |
|---|
|
pub async fn impl is monomorphized when func itself is monomorphized
Implentation coroutine (`func::{closure#0}`) is monomorphized, when func itself is monomorphized.
Currently, when `pub async fn foo(..)` is exported from lib and used in several dependent crates, only 'header' function is monomorphized in the defining crate. 'header' function, returning coroutine object, is monomorphized, but the coroutine's poll function (which actually implements all the logic for the function) is not. In such situation, `func::{closure#0}` will be monomorphized in every dependency.
This PR adds monomorphization for `func::{closure#0}` (coroutine poll function), when func itself is monomorphized.
Simple test with one lib async function and ten dependent crates (executable) that use the function, shows 5-7% compilation time improvement (single-threaded).
|
|
when func itself is monomorphized
|
|
|
|
|
|
|
|
This flag turned out to be less useful than anticipated, and interferes with
work towards expansion support.
|
|
This allows us to assume that coverage spans will only be discarded during
codegen in very unusual situations.
|
|
|
|
|
|
The bug was triggered by a particular usage of the `?` try operator in a
proc-macro expansion.
Thanks to lqd for the minimization.
Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>
|
|
This reverts commit f877aa7d14916f71a2f88c6d4c009e7ded7684c4.
|
|
This allows us to assume that coverage spans will only be discarded during
codegen in very unusual situations.
|
|
|
|
This reverts commit 3b22c21dd8c30f499051fe7a758ca0e5d81eb638, reversing
changes made to 5f292eea6d63abbd26f1e6e00a0b8cf21d828d7d.
|
|
This case can't actually happen yet (other than via a testing flag), because
currently all of a function's spans must belong to the same file and expansion.
But this will be an important edge case when adding expansion region support.
|
|
This allows us to assume that coverage spans will only be discarded during
codegen in very unusual situations.
|
|
This also removes some manipulation of the function signature span that only
made sense in the context of merging non-adjacent spans.
|
|
|
|
|
|
|
|
This reverts commit 906f66fb4c22daa8a6f97e5c048e9f6ab3fd9051.
|
|
|
|
|
|
This is a way to shrink call spans that doesn't involve mixing different spans,
and avoids overlap with argument spans.
This patch also removes some low-value comments that were causing rustfmt to
ignore the match arms.
|
|
This test is intended to demonstrate that a particular macro-argument span
doesn't get lost during span-refinement, but it turns out that span-extraction
currently doesn't yield any MIR spans for this position.
This patch therefore tweaks the test to add a function call in that position,
so that it still remains relevant to span refinement.
|
|
|
|
|
|
When preparing a function's coverage counters and metadata during codegen, any
part of the original coverage graph that was removed by MIR optimizations can
be treated as having an execution count of zero.
Somewhat counter-intuitively, if we give those unreachable nodes a _higher_
priority for receiving physical counters (instead of counter expressions), that
ends up reducing the total number of physical counters needed.
This works because if a node is unreachable, we don't actually create a
physical counter for it. Instead that node gets a fixed zero counter, and any
other node that would have relied on that physical counter in its counter
expression can just ignore that term completely.
|
|
|
|
|
|
|
|
|
|
|
|
r=wesleywiser"
This reverts commit 1d35638dc38dbfbf1cc2a9823135dfcf3c650169, reversing
changes made to f23a80a4c2fbca593b64e70f5970368824b4c5e9.
|
|
coverage: Store coverage source regions as `Span` until codegen (take 2)
This is an attempt to re-land #133418:
> Historically, coverage spans were converted into line/column coordinates during the MIR instrumentation pass.
> This PR moves that conversion step into codegen, so that coverage spans spend most of their time stored as Span instead.
> In addition to being conceptually nicer, this also reduces the size of coverage mappings in MIR, because Span is smaller than 4x u32.
That PR was reverted by #133608, because in some circumstances not covered by our test suite we were emitting coverage metadata that was causing `llvm-cov` to exit with an error (#133606).
---
The implementation here is *mostly* the same, but adapted for subsequent changes in the relevant code (e.g. #134163).
I believe that the changes in #134163 should be sufficient to prevent the problem that required the original PR to be reverted. But I haven't been able to reproduce the original breakage in a regression test, and the `llvm-cov` error message is extremely unhelpful, so I can't completely rule out the possibility of this breaking again.
r? jieyouxu (reviewer of the original PR)
|
|
|
|
|
|
coverage: Dismantle `map_data.rs` by moving its responsibilities elsewhere
This is a series of incremental changes that combine to let us get rid of `coverageinfo/map_data.rs`, by moving all of its responsibilities into more appropriate places.
Some of the notable consequences are:
- We once again build the per-CGU file table on the fly while preparing individual covfun records, instead of building the whole table up-front. The up-front approach was introduced by #117042 to work around various other problems in generating the covmap/covfun records, but subsequent cleanups have made that approach no longer necessary.
- Expression conversion and mapping-region conversion are now performed directly in `mapgen::covfun`, which should make future changes easier.
- We no longer insert unused function instances into the same map that is also used to track used function instances. This helps to decouple the handling of used vs unused functions.
---
There should be no meaningful change to compiler output. The file table is no longer sorted, because reordering it would invalidate the file indices stored in individual covfun records, but the table order should still be deterministic (albeit arbitrary).
There are some subsequent cleanups that I intend to investigate, but this is enough change for one PR.
|
|
|
|
|
|
|
|
|
|
Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
Do not unify dereferences of shared borrows in GVN
Repost of https://github.com/rust-lang/rust/pull/132461, the last commit applies my suggestions.
Fixes https://github.com/rust-lang/rust/issues/130853
|
|
|
|
|
