rust/compiler/rustc_query_impl/src/plumbing.rs, branch 1.62.0

Enable tracing for all queryies

2022-05-04T16:15:26+00:00

Auto merge of #94084 - Mark-Simulacrum:drop-sharded, r=cjgillot

2022-02-27T14:04:07+00:00

Avoid query cache sharding code in single-threaded mode In non-parallel compilers, this is just adding needless overhead at compilation time (since there is only one shard statically anyway). This amounts to roughly ~10 seconds reduction in bootstrap time, with overall neutral (some wins, some losses) performance results. Parallel compiler performance should be largely unaffected by this PR; sharding is kept there.

Auto merge of #94066 - Mark-Simulacrum:factor-out-simple-def-kind, r=davidtwco

2022-02-21T03:36:55+00:00

Remove SimpleDefKind Now that rustc_query_system depends on rustc_hir, we can just directly make use of the regular DefKind.

Delete QueryLookup

2022-02-20T17:11:28+00:00

This was largely just caching the shard value at this point, which is not particularly useful -- in the use sites the key was being hashed nearby anyway.

Move Sharded maps into each QueryCache impl

2022-02-20T17:10:46+00:00

Remove SimpleDefKind

2022-02-17T23:08:45+00:00

Move ty::print methods to Drop-based scope guards

2022-02-16T22:24:23+00:00

Auto merge of #93741 - Mark-Simulacrum:global-job-id, r=cjgillot

2022-02-09T18:54:30+00:00

Refactor query system to maintain a global job id counter This replaces the per-shard counters with a single global counter, simplifying the JobId struct down to just a u64 and removing the need to pipe a DepKind generic through a bunch of code. The performance implications on non-parallel compilers are likely minimal (this switches to `Cell` as the backing storage over a `u64`, but the latter was already inside a `RefCell` so it's not really a significance divergence). On parallel compilers, the cost of a single global u64 counter may be more significant: it adds a serialization point in theory. On the other hand, we can imagine changing the counter to have a thread-local component if it becomes worrisome or some similar structure. The new design is sufficiently simpler that it warrants the potential for slight changes down the line if/when we get parallel compilation to be more of a default. A u64 counter, instead of u32 (the old per-shard width), is chosen to avoid possibly overflowing it and causing problems; it is effectively impossible that we would overflow a u64 counter in this context.

Switch QueryJobId to a single global counter

2022-02-08T23:49:55+00:00

This replaces the per-shard counters with a single global counter, simplifying the JobId struct down to just a u64 and removing the need to pipe a DepKind generic through a bunch of code. The performance implications on non-parallel compilers are likely minimal (this switches to `Cell` as the backing storage over a `u64`, but the latter was already inside a `RefCell` so it's not really a significance divergence). On parallel compilers, the cost of a single global u64 counter may be more significant: it adds a serialization point in theory. On the other hand, we can imagine changing the counter to have a thread-local component if it becomes worrisome or some similar structure. The new design is sufficiently simpler that it warrants the potential for slight changes down the line if/when we get parallel compilation to be more of a default. A u64 counter, instead of u32 (the old per-shard width), is chosen to avoid possibly overflowing it and causing problems; it is effectively impossible that we would overflow a u64 counter in this context.

14956 -> 14952 exports

2022-02-07T21:13:31+00:00