fix: change detection for fixpoint queries by MichaReiser · Pull Request #836 · salsa-rs/salsa

MichaReiser · 2025-04-30T14:55:05Z

This PR fixes two bugs in maybe_changed_after for cyclic queries

Fix number 1

Salsa doesn't invalidate a cycle of query_a -> query_b if query_b only depends on the input in the first iteration.

Fixing this requires that we carry over inputs to later iterations. This is a very similar fix to what I did for tracked structs.

This fixes #834.

Fix number 2

We saw many access to interned struct that wasn't interned in this revision panics. This was caused by maybe_changed_after re-running a query in the attempt to backdate it even when the query participates in a cycle (in which case salsa returned Fixpoint initial on which the query that Salsa tries to backdate now depends on). This is problematic the assumption before calling execute is that all its inputs are valid but this isn't the case when returning fixpoint initial, Salsa then intentionally defers validating all the input/outputs.

The fix here is to only perform the backdating if not in a cycle. If incide a cycle, then the backdating must happen for the cycle head (which then calls maybe_changed_after of inner queries again)

Performance

The performance results on ty (former Red Knot) are neutral. The performance should mainly regress if cycles have many different inputs/outputs between iterations because they're now carried over

netlify · 2025-04-30T14:55:23Z

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	`f702cd5`
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/6819c1fd459a8000083befa6

codspeed-hq · 2025-04-30T14:56:21Z

CodSpeed Performance Report

Merging #836 will degrade performances by 10.44%

_{Comparing MichaReiser:fix-missing-iteration-inputs (f702cd5) with master (2c04176)}

Summary

❌ 1 (👁 1) regressions
✅ 11 untouched benchmarks

Benchmarks breakdown

	Benchmark	`BASE`	`HEAD`	Change
👁	`converge_diverge`	129.8 µs	144.9 µs	-10.44%

MichaReiser · 2025-05-01T07:32:42Z

It's not entirely clear what behavior we want for accumulated values. E.g. a depends on b but only in its first iteration and b emits an accumulated value. Is that value now returned when retrieving the accumulated values of a?

If no, then we'll need a way to distinguish between dependencies from the current and previous iterations.

MichaReiser · 2025-05-05T08:20:07Z

tests/cycle_output.rs

-            "salsa_event(DidValidateMemoizedValue { database_key: read_value(Id(403)) })",
+            "salsa_event(DidValidateMemoizedValue { database_key: read_value(Id(400)) })",
+            "salsa_event(DidReinternValue { key: query_d::interned_arguments(Id(800)), revision: R2 })",
+            "salsa_event(WillExecute { database_key: query_b(Id(0)) })",


This test captures fix 2. Salsa tries to see if query_b changed (cycle head). query_b depends on query_a and query_a depends on query_b and query_d.

Salsa returns a provisional value for query_b.

Before

maybe_changed_after:

query_b: Unchanged

query_a:

Calls maybe_changed_after for query_b: Returns Unchanged (but fixpoint initial)

Calls maybe_changed_after for query_d: Detects that one input changed. Tries backdating by executing the query (which isn't safe because it may depend on a struct interned by query_b which was never fully verified

Now

query_d now returns Changed without trying to backdate, same for query_a because both see that they're part of a cycle. Salsa then executes query_b, which may get backdated.

And I guess since you reverted the earlier (not really right) change I'd made to avoid having output-validation fail in this case, this test will also now fail without the other fix in this PR (and not only due to the log assertions.)

MichaReiser · 2025-05-05T08:25:13Z

src/function/maybe_changed_after.rs

+            QueryOrigin::FixpointInitial if old_memo.may_be_provisional() => {
+                VerifyResult::changed()
            }
-            QueryOrigin::FixpointInitial if old_memo.may_be_provisional() => VerifyResult::Changed,
            QueryOrigin::FixpointInitial => VerifyResult::unchanged(),


@carljm I'm not 100% sure about the two fixpoint arms here.

I'm not either :) I don't have a memory of why this is this way -- maybe it was needed in some much-earlier version of fixpoint iteration?

Locally it seems that replacing both arms with this doesn't fail any tests, and it feels more clearly correct (but I'd want to also check it for perf regression on ty):

QueryOrigin:FixpointInitial => VerifyResult::changed(),

This makes me wonder if we even need this extra variant or if we could just use Derived everywhere because we also have revisions.maybe_changed_after to identify provisional values.

carljm

So good!!

This all makes sense to me, fantastic work.

carljm · 2025-05-05T18:13:35Z

tests/cycle_output.rs

-            "salsa_event(DidValidateMemoizedValue { database_key: read_value(Id(403)) })",
+            "salsa_event(DidValidateMemoizedValue { database_key: read_value(Id(400)) })",
+            "salsa_event(DidReinternValue { key: query_d::interned_arguments(Id(800)), revision: R2 })",
+            "salsa_event(WillExecute { database_key: query_b(Id(0)) })",


And I guess since you reverted the earlier (not really right) change I'd made to avoid having output-validation fail in this case, this test will also now fail without the other fix in this PR (and not only due to the log assertions.)

carljm · 2025-05-05T18:23:19Z

tests/cycle_maybe_changed_after.rs

+fn query_a_initial(_db: &dyn Database, _input: Input) -> u32 {
+    0
+}
+
+fn query_a_recover(


Maybe these shouldn't be named query_a_* since they are used by both query_a and query_d? Looks a bit weird above.

carljm · 2025-05-05T18:34:53Z

src/function/maybe_changed_after.rs

+            QueryOrigin::FixpointInitial if old_memo.may_be_provisional() => {
+                VerifyResult::changed()
            }
-            QueryOrigin::FixpointInitial if old_memo.may_be_provisional() => VerifyResult::Changed,
            QueryOrigin::FixpointInitial => VerifyResult::unchanged(),


I'm not either :) I don't have a memory of why this is this way -- maybe it was needed in some much-earlier version of fixpoint iteration?

Locally it seems that replacing both arms with this doesn't fail any tests, and it feels more clearly correct (but I'd want to also check it for perf regression on ty):

QueryOrigin:FixpointInitial => VerifyResult::changed(),

MichaReiser force-pushed the fix-missing-iteration-inputs branch 2 times, most recently from 5a435a7 to 953dc34 Compare April 30, 2025 15:06

MichaReiser added 2 commits May 4, 2025 19:13

bug: Fix missing cycle inputs

12ba96a

Pass provisional as old memo to execute_query during fixpoint

22a383b

MichaReiser force-pushed the fix-missing-iteration-inputs branch from 9036ecf to 22a383b Compare May 4, 2025 17:15

MichaReiser added 2 commits May 4, 2025 19:21

Remove provisional from remove stale output

8304576

Revert debug code

4326d49

MichaReiser mentioned this pull request May 5, 2025

Update salsa to pull in fixpoint fixes astral-sh/ruff#17847

Merged

MichaReiser added 3 commits May 5, 2025 09:30

Update test

fba7ef8

Some documentation

40bdfab

Clean up tests

3db05ed

MichaReiser changed the title ~~fix: Cycles with conditional input-dependencies~~ fix: change detection for fixpoint queries May 5, 2025

Fix for direct enclosing query

f268ef0

MichaReiser commented May 5, 2025

View reviewed changes

Format

79b9317

MichaReiser marked this pull request as ready for review May 5, 2025 08:20

MichaReiser added the bug Something isn't working label May 5, 2025

More comment fiddling

dce29e3

MichaReiser commented May 5, 2025

View reviewed changes

Revert copy only outputs change

ecf8d8e

carljm approved these changes May 5, 2025

View reviewed changes

MichaReiser added 5 commits May 6, 2025 09:16

Revert fixpoint_initial start revision change (worth its own PR)

d8ca6f3

Align fixpoint handling with Derived

7185ef3

Preserve cycle heads when returning fixpoint initial

af695e1

Always return changed for Fixpoint::Initial

03198bf

Keep returning unchanged in some cases

f702cd5

MichaReiser enabled auto-merge May 6, 2025 08:02

MichaReiser added this pull request to the merge queue May 6, 2025

Merged via the queue into salsa-rs:master with commit b2b82bc May 6, 2025
11 checks passed

MichaReiser deleted the fix-missing-iteration-inputs branch May 6, 2025 08:22

github-actions bot mentioned this pull request May 2, 2025

chore: release v0.22.0 #840

Merged

Veykril mentioned this pull request May 6, 2025

assertion failed: existing.iteration_count == head.iteration_count #831

Closed

This was referenced May 6, 2025

fix: incorrect caching for queries participating in fixpoint #843

Merged

Lazy finalization of cycle participants in maybe_changed_after #854

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: change detection for fixpoint queries#836

fix: change detection for fixpoint queries#836
MichaReiser merged 16 commits intosalsa-rs:masterfrom
MichaReiser:fix-missing-iteration-inputs

MichaReiser commented Apr 30, 2025 •

edited

Loading

Uh oh!

netlify bot commented Apr 30, 2025 •

edited

Loading

Uh oh!

codspeed-hq bot commented Apr 30, 2025 •

edited

Loading

Uh oh!

MichaReiser commented May 1, 2025

Uh oh!

MichaReiser May 5, 2025

Uh oh!

carljm May 5, 2025

Uh oh!

MichaReiser May 5, 2025

Uh oh!

carljm May 5, 2025

Uh oh!

MichaReiser May 6, 2025

Uh oh!

carljm left a comment

Uh oh!

carljm May 5, 2025

Uh oh!

carljm May 5, 2025

Uh oh!

carljm May 5, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

MichaReiser commented Apr 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Fix number 1

Fix number 2

Performance

Uh oh!

netlify bot commented Apr 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for salsa-rs canceled.

Uh oh!

codspeed-hq bot commented Apr 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merging #836 will degrade performances by 10.44%

Summary

Benchmarks breakdown

Uh oh!

MichaReiser commented May 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carljm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

MichaReiser commented Apr 30, 2025 •

edited

Loading

netlify bot commented Apr 30, 2025 •

edited

Loading

codspeed-hq bot commented Apr 30, 2025 •

edited

Loading