Encode spans relative to the enclosing item

[cjgillot]

The aim of this PR is to avoid recomputing queries when code is moved without modification.

MCP at rust-lang/compiler-team#443

This is achieved by :

1. storing the HIR owner LocalDefId information inside the span;
2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache;
3. marking a dependency to the source_span(LocalDefId) query when we translate a span from the short (Span) representation to its explicit (SpanData) representation.

Since all client code uses Span, step 3 ensures that all manipulations
of span byte positions actually create the dependency edge between
the caller and the source_span(LocalDefId).
This query return the actual absolute span of the parent item.
As a consequence, any source code motion that changes the absolute byte position of a node will either:

• modify the distance to the parent's beginning, so change the relative span's hash;
• dirty source_span, and trigger the incremental recomputation of all code that
  depends on the span's absolute byte position.

With this scheme, I believe the dependency tracking to be accurate.

For the moment, the spans are marked during lowering.
I'd rather do this during def-collection,
but the AST MutVisitor is not practical enough just yet.
The only difference is that we attach macro-expanded spans
to their expansion point instead of the macro itself.

[petrochenkov]

I don't like the idea of keeping the ID in SpanData and would like to see a separate type for this, like LoweredSpan.
I see why it was faster to prototype this with a single Span type though.

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit d861775a3095b6bc7b23e4dc2acfb30a82f104c2 with merge 53c860c88de8437287861ee8c26eaedbe95dd7fb...

[cjgillot]

I don't like the idea of keeping the ID in SpanData and would like to see a separate type for this, like LoweredSpan.
I see why it was faster to prototype this with a single Span type though.

On the one hand, I agree with you, putting the ID in the SpanData is a bad hack, and invites silent invalidations.
On the other hand, I would like to assign the stable spans in the AST, to make macro-expanded spans relative to the enclosing macro.

I shall think a bit more about it. Creating a hir::Span and putting it everywhere is probably the most robust option.

[bors]

☀️ Try build successful - checks-actions
Build commit: 53c860c88de8437287861ee8c26eaedbe95dd7fb (53c860c88de8437287861ee8c26eaedbe95dd7fb)

[rust-timer]

Queued 53c860c88de8437287861ee8c26eaedbe95dd7fb with parent 2b68027, future comparison URL.

[cjgillot]

perf report : bad (I mean don't look, its really bad).
I think I've been too heavy handed in querifying source_map, which pessimizes MIR and CGU reuse.

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[cjgillot]

@bors r=michaelwoerister,petrochenkov

About the perf regression: this PR implements an opt-in feature to reduce span-related recomputations for incr-comp. Measurements in #84762 show up to -25% instruction reduction when enabled. When disabled, the perf hit appears to be a consistent 1-2% instruction hit.

[bors]

📌 Commit 7842b80 has been approved by michaelwoerister,petrochenkov

[bors]

⌛ Testing commit 7842b80 with merge 547d937...

[bors]

☀️ Test successful - checks-actions
Approved by: michaelwoerister,petrochenkov
Pushing 547d937 to master...

[rust-timer]

Finished benchmarking commit (547d937): comparison url.

Summary: This change led to large relevant regressions 😿 in compiler performance.

• Large regression in instruction counts (up to 2.1% on incr-unchanged builds of tuple-stress)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

[Mark-Simulacrum]

About the perf regression: this PR implements an opt-in feature to reduce span-related recomputations for incr-comp. Measurements in #84762 show up to -25% instruction reduction when enabled. When disabled, the perf hit appears to be a consistent 1-2% instruction hit.

So seems justified and action on this PR not expected.