Equivalence propagation #24155

frankmcsherry · 2023-12-29T22:16:29Z

Transformation that propagates "equivalence" information, of the form expr1 = expr2 under Rust's =. This allows us to communicate arbitrary predicates (expr = true) but also compactly represent normalizing equivalences that equate classes of expressions (and allow substitution by the simplest representatives).

At the moment, it optimizes away queries like

-- Demonstrates absence of cross-join input sharing.
SELECT COUNT(*) FROM 
    (SELECT * FROM foo WHERE foo.a = 7) foo,
    (SELECT * FROM bar WHERE bar.a < 5) bar
WHERE foo.a = bar.a;

but should be more fully explored to see what it does to expressions, and whether it mis-optimizes any. This PR is meant to read out any test failures in that regard.

The longer term goal is to consolidate places where we try and reason about "equivalence" in ad-hoc manners. There are several transforms that overlap with this reasoning, and several of them could be simplified, improved, or potentially just removed. They include:

Predicate pushdown (encourage Get nodes to house predicates, and provide guarantees for users)
Literal lifting (identify columns as literals, and remove dependence on the columns themselves)
Column knowledge (identify columns as literals or non-null. more generally, other predicates of columns)
Non-null requirements (push down the information that rows with null columns can be dropped)
Nonnullability (harvest more accurate information about non-nullability than typ() provides)
Predicate canonicalization (Filter-local predicate simplification that now extends further)
Demand analysis (identify equivalent columns to reduce demand on one of them)

The main gotcha at the moment is that several of the above perform light physical plan modification as they go. For example LiteralLifting projects away any lifted columns, in addition to highlighting the information that the column is a literal. To do this it goes through a bunch of permutation pain, but it ends up with an expression that for example removes unit join terms, where without the projection they are a column containing unread data that we don't know how to prune (the code was never written).

Motivation

Tips for reviewer

Checklist

This PR has adequate test coverage / QA involvement has been duly considered.
This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
This PR includes the following user-facing behavior changes:

This PR introduces an `Analysis` trait that is meant to be a simplification of the `Attribute` trait/framework. It is simpler in many ways, and less expressive, but seemingly the restrictions are not yet limiting and are potentially helpful in broadening the uptake of the framework. The main idea is that an `Analysis` implementor specifies an output type it will produce for each expression, and the logic that produces this output given an expression, analysis results for child expressions, and analysis results for other depended-upon analyses. All analysis state is indexed by "offset": the post-order visitation numbering of the expressions. The framework runs the analyses in dependency order, establishes links between `Let`-bound identifiers and offsets, but otherwise has very few opinions. By contrast, the Attribute framework allowed its hosted attributes to propose various bits of logic that would run in addition as it traverses an expression, used to set up `Let`-binding information but also potentially much more. There is a demonstration of how to use the framework in #24155, but we are looking at this PR in isolation to break up the moving parts of that PR into manageable pieces. 1. The main annoyance in using the output is that one must keep notes as one descends into an expression about the current expression offsets, as very little help is currently offered here (though, a `Slice` variant of the results that scopes itself down to expressions, and their child expressions, would probably be helpful). 2. There is a fair amount of cloning of results, even though many expressions only wish to say "whatever my only child says". One could imagine an analysis result type of `Result<AnalysisType, usize>` where the `Err(offset)` variant might indicate an offset to consult for the state (and expressions that don't modify the analysis result could have `Err(offset)` for some appropriate `offset` (their child, or whereever their child references). The main reviewing question is whether this simplification is net valuable, in that it makes things easier to use and adopt, without ruling out too much expressivity or potentially performance. Additionally, I have not yet begun to integrate it further than the previous PR, but I'm happy to follow up with commits that do this if we identify where we could most fruitfully slice out the existing uses. I put together prototype versions for all existing attributes other than `Cardinality` and `ColumnNames`, as they each had a fair bit of inherent complexity. ### Motivation  ### Tips for reviewer  ### Checklist - [ ] This PR has adequate test coverage / QA involvement has been duly considered. - [ ] This PR has an associated up-to-date [design doc](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/README.md), is a design doc ([template](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/00000000_template.md)), or is sufficiently small to not require a design.  - [ ] If this PR evolves [an existing `$T ⇔ Proto$T` mapping](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/command-and-response-binary-encoding.md) (possibly in a backwards-incompatible way), then it is tagged with a `T-proto` label. - [ ] If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label ([example](MaterializeInc/cloud#5021)).  - [ ] This PR includes the following [user-facing behavior changes](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/guide-changes.md#what-changes-require-a-release-note): -

src/transform/src/equivalence_propagation.rs

test/sqllogictest/transform/predicate_pushdown.slt

ggevay

I'll continue reading the code tomorrow, but I'm sending my comments so far.

src/transform/src/analysis/equivalences.rs

test/sqllogictest/transform/predicate_pushdown.slt

src/transform/src/attribute/analysis.rs

src/transform/src/analysis/equivalences.rs

ggevay · 2024-02-26T19:07:09Z

src/transform/src/analysis/equivalences.rs

+            classes: Vec::new(),
+        };
+        for class1 in self.classes.iter() {
+            for class2 in other.classes.iter() {


Could you please add some limit here that just gives up if self.classes.len() * other.classes.len() is too large? (I've already seen a join in a customer's MIR plan with 196 equivalences...)

I'm conflicted on this, given the status of the codebase and the struggles with predictability of transforms. If we can figure out a principled way to do this that doesn't fight with idempotence, that doesn't make the outer fixpoint iteration brittle, etc., then yes! But if it's "don't do something quadratic in the input" then .. we have larger problems. :D

Ah, looking at the code there is a fine linear time implementation (move to HashSets for intersection). Does that work for you?

Maybe we'll never run into the limit. How about you add a soft_assert_or_log? And then CI would fail if we run into the limit, and in production we'd get a Sentry error. And then if it never happens then everyone is happy, and if it happens then we can figure out the next steps (increasing the limit, optimizing the code, ignoring the problem if it doesn't look dangerous that the optimization was not applied in the specific situation, ...).

Ah, I've only now seen your comment about using HashSets. I'm not sure how to do it with HashSets, but a possible approach would be to have a HashMap that maps from expressions to indexes in classes (relying on the fact that minimize makes it so that each expression can appear in only one class). And a similar thing should also work for my other similar comment.

src/transform/src/analysis/equivalences.rs

ggevay · 2024-02-26T19:29:31Z

src/transform/src/analysis/equivalences.rs

+            //          They stop being sorted as soon as we make any modification, though.
+            //          But, it would be a fast rejection when faced with lots of data.
+            for index1 in 0..self.classes.len() {
+                for index2 in 0..index1 {


Same comment as in union: could you please add a safety limit?

src/transform/src/analysis/equivalences.rs

ggevay · 2024-02-26T21:43:06Z

Even with the above complete = false; issue fixed, EquivalenceClasses::minimize is somehow still not idempotent: I ran all slts with the following assert added, and it's failing for test/sqllogictest/window_funcs.slt:
ggevay@b95a39e
(The commit runs a copy of minimize again at the end of minimize. The copy is to make it not run itself infinitely.)

E.g.:

thread 'tokio-runtime-worker' panicked at src/transform/src/analysis/equivalences.rs:352:9:
assertion `left == right` failed
  left: EquivalenceClasses { classes: [[Literal(Ok(Row{[True]}), ColumnType { scalar_type: Bool, nullable: false }), CallUnary { func: Not(Not), expr: CallUnary { func: IsNull(IsNull), expr: CallUnary { func: RecordGet(RecordGet(0)), expr: CallUnary { func: RecordGet(RecordGet(1)), expr: Column(2) } } } }], [CallUnary { func: RecordGet(RecordGet(0)), expr: Column(2) }, CallUnary { func: CastInt32ToInt64(CastInt32ToInt64), expr: CallUnary { func: RecordGet(RecordGet(0)), expr: CallUnary { func: RecordGet(RecordGet(1)), expr: Column(2) } } }]] }
 right: EquivalenceClasses { classes: [[Literal(Ok(Row{[True]}), ColumnType { scalar_type: Bool, nullable: false }), CallUnary { func: Not(Not), expr: CallUnary { func: IsNull(IsNull), expr: CallUnary { func: RecordGet(RecordGet(0)), expr: Column(2) } } }, CallUnary { func: Not(Not), expr: CallUnary { func: IsNull(IsNull), expr: CallUnary { func: RecordGet(RecordGet(0)), expr: CallUnary { func: RecordGet(RecordGet(1)), expr: Column(2) } } } }], [CallUnary { func: RecordGet(RecordGet(0)), expr: Column(2) }, CallUnary { func: CastInt32ToInt64(CastInt32ToInt64), expr: CallUnary { func: RecordGet(RecordGet(0)), expr: CallUnary { func: RecordGet(RecordGet(1)), expr: Column(2) } } }]] }
stack backtrace:
   0: rust_begin_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:72:14
   2: core::panicking::assert_failed_inner
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:342:17
   3: core::panicking::assert_failed
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking.rs:297:5
   4: mz_transform::analysis::equivalences::EquivalenceClasses::minimize
             at ./src/transform/src/analysis/equivalences.rs:352:9
   5: <mz_transform::analysis::equivalences::Equivalences as mz_transform::analysis::Analysis>::derive
             at ./src/transform/src/analysis/equivalences.rs:176:9
   6: <mz_transform::analysis::common::Bundle<A> as mz_transform::analysis::common::AnalysisBundle>::analyse
             at ./src/transform/src/analysis.rs:345:25
   7: mz_transform::analysis::common::DerivedBuilder::visit
             at ./src/transform/src/analysis.rs:319:25
   8: <mz_transform::equivalence_propagation::EquivalencePropagation as mz_transform::Transform>::transform
             at ./src/transform/src/equivalence_propagation.rs:61:23
   9: <mz_transform::Fixpoint as mz_transform::Transform>::transform::{{closure}}
             at ./src/transform/src/lib.rs:279:25
  10: tracing::span::Span::in_scope
             at /home/gabor/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tracing-0.1.37/src/span.rs:1102:9
  11: <mz_transform::Fixpoint as mz_transform::Transform>::transform
             at ./src/transform/src/lib.rs:277:17
  12: mz_transform::Optimizer::transform
             at ./src/transform/src/lib.rs:663:13
  13: mz_transform::Optimizer::optimize
             at ./src/transform/src/lib.rs:626:32
  14: mz_adapter::optimize::optimize_mir_local
             at ./src/adapter/src/optimize/mod.rs:312:16
  15: <mz_adapter::optimize::peek::Optimizer as mz_adapter::optimize::Optimize<mz_sql::plan::expr::HirRelationExpr>>::optimize
             at ./src/adapter/src/optimize/peek.rs:158:20
  16: mz_adapter::optimize::Optimize::catch_unwind_optimize::{{closure}}
             at ./src/adapter/src/optimize/mod.rs:120:63
  17: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panic/unwind_safe.rs:272:9
  18: std::panicking::try::do_call
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:552:40
  19: __rust_try
  20: std::panicking::try
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:516:19
  21: std::panic::catch_unwind
             at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panic.rs:142:14
  22: mz_ore::panic::catch_unwind::{{closure}}
             at ./src/ore/src/panic.rs:78:19
...

This PR introduces an `Analysis` trait that is meant to be a simplification of the `Attribute` trait/framework. It is simpler in many ways, and less expressive, but seemingly the restrictions are not yet limiting and are potentially helpful in broadening the uptake of the framework. The main idea is that an `Analysis` implementor specifies an output type it will produce for each expression, and the logic that produces this output given an expression, analysis results for child expressions, and analysis results for other depended-upon analyses. All analysis state is indexed by "offset": the post-order visitation numbering of the expressions. The framework runs the analyses in dependency order, establishes links between `Let`-bound identifiers and offsets, but otherwise has very few opinions. By contrast, the Attribute framework allowed its hosted attributes to propose various bits of logic that would run in addition as it traverses an expression, used to set up `Let`-binding information but also potentially much more. There is a demonstration of how to use the framework in #24155, but we are looking at this PR in isolation to break up the moving parts of that PR into manageable pieces. 1. The main annoyance in using the output is that one must keep notes as one descends into an expression about the current expression offsets, as very little help is currently offered here (though, a `Slice` variant of the results that scopes itself down to expressions, and their child expressions, would probably be helpful). 2. There is a fair amount of cloning of results, even though many expressions only wish to say "whatever my only child says". One could imagine an analysis result type of `Result<AnalysisType, usize>` where the `Err(offset)` variant might indicate an offset to consult for the state (and expressions that don't modify the analysis result could have `Err(offset)` for some appropriate `offset` (their child, or whereever their child references). The main reviewing question is whether this simplification is net valuable, in that it makes things easier to use and adopt, without ruling out too much expressivity or potentially performance. Additionally, I have not yet begun to integrate it further than the previous PR, but I'm happy to follow up with commits that do this if we identify where we could most fruitfully slice out the existing uses. I put together prototype versions for all existing attributes other than `Cardinality` and `ColumnNames`, as they each had a fair bit of inherent complexity. ### Motivation  ### Tips for reviewer  ### Checklist - [ ] This PR has adequate test coverage / QA involvement has been duly considered. - [ ] This PR has an associated up-to-date [design doc](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/README.md), is a design doc ([template](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/00000000_template.md)), or is sufficiently small to not require a design.  - [ ] If this PR evolves [an existing `$T ⇔ Proto$T` mapping](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/command-and-response-binary-encoding.md) (possibly in a backwards-incompatible way), then it is tagged with a `T-proto` label. - [ ] If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label ([example](MaterializeInc/cloud#5021)).  - [ ] This PR includes the following [user-facing behavior changes](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/guide-changes.md#what-changes-require-a-release-note): -

ggevay · 2024-03-02T15:11:28Z

src/transform/src/analysis/equivalences.rs

+                (_, MirScalarExpr::Literal(_, _)) => std::cmp::Ordering::Greater,
+                (MirScalarExpr::Column(_), MirScalarExpr::Column(_)) => e1.cmp(e2),
+                (MirScalarExpr::Column(_), _) => std::cmp::Ordering::Less,
+                (_, MirScalarExpr::Column(_)) => std::cmp::Ordering::Greater,


Could you add a comment here mentioning that the first elements of the classes are the representatives, and these ordering considerations are important because we'll be simplifying expressions to these representatives?

ggevay · 2024-03-02T15:13:31Z

src/transform/src/analysis/equivalences.rs

+        self.classes.dedup();
+    }
+
+    /// Update `self` to maintain the same equivalences which potentially reducing along `Ord::le`.


Whose Ord::le is this sentence referring to?

ggevay · 2024-03-02T15:55:21Z

src/transform/src/analysis/equivalences.rs

+        // TODO: remove these measures once we are more confident about idempotence.
+        let prev = self.clone();
+        self.minimize_once(columns);
+        assert_eq!(self, &prev);


Copying here from Slack:
I'd suggest to leave the idempotence assertion in the code (as a soft_assert_or_log) until we test this on customer queries.

ggevay · 2024-03-04T17:55:32Z

I've started a Nightly CI run on the current version: https://buildkite.com/materialize/nightlies/builds/6753

Alex says he'll run RQG tomorrow. He will also add a feature flag as discussed here.

aalexandrov

After the latest fix I couldn't find any more correctness issues.

I suggest to wait for me to rebase and push a commit that add the transform behind a feature flag and enables it in CI before we merge this PR. This can be done immediate after #25628 and #25812 are merged, so probably later today.

@def-: you'll have to ping me next week if the SQLSmith / RQG failures due to OOMs become too frequent. Once we have good example queries I can try tracing with and without the feature flag turned on to see what (if anything) is causing the extra memory consumtion.

aalexandrov · 2024-03-08T13:53:24Z

src/transform/src/equivalence_propagation.rs

+    /// The mutations should never invalidate an equivalence the operator has been reported as providing, as that
+    /// information may have already been acted upon by others.
+    ///
+    /// The `expr_index` argument must equal `expr`s position in post-order, so that it can be used as a reference


There is no expr_index mentioned else in this file.

Happy to fix, but maybe after it's in a state that you like / it gets merged. Mostly want to avoid randomizing things with my primitive git skills.

shepherdlybot · 2024-03-08T20:02:15Z

Mitigations

Completing required mitigations increases Resilience Coverage.

(Required) Code Review 🔍 Detected
(Required) Feature Flag
(Required) Integration Test 🔍 Detected
(Required) Observability
(Required) QA Review 🔍 Detected
Unit Test

Risk Summary:

The risk associated with this pull request is high, with a score of 83, indicating a significant likelihood of introducing bugs. This assessment is informed by factors such as the average line count in files and the number of executable lines within files, which historically have made pull requests 141% more likely to cause a bug compared to the baseline. Additionally, the pull request modifies files that have a recent history of bug fixes. The repository's observed bug trend is currently decreasing, which is separate from the risk score but suggests an improvement in the overall code stability.

Note: The risk score is not based on semantic analysis but on historical predictors of bug occurrence in the repository. The attributes above were deemed the strongest predictors based on that history. Predictors and the score may change as the PR evolves in code, time, and review activity.

Bug Hotspots:
What's This?

File	Percentile
../statement/ddl.rs	96

We discussed with Gábor that further change requests can be addressed in a follow up PR since we are merging this behind a feature flag that is off by default.

jkosh44

Adapter code LGTM

jkosh44 · 2024-03-08T20:21:13Z

src/sql-parser/src/ast/defs/statement.rs

Is there a parser test we can add for these changes in https://github.com/MaterializeInc/materialize/tree/main/src/sql-parser/tests/testdata

@jkosh44 I think you are flagged when I force-pushed my feature flag commits, because in those I extended the parser in order to allow overriding the new feature flag at the SQL level in EXPLAIN WITH(...) and CREATE CLUSTER ... FEATURES(...).

We already have parser tests for this syntax. I don't think it's worth it to add specific specific tests for each new feature flag that we define.

We might want to improve the ergonomics of building a vector of transforms with optional feature flags with a macro.

Export the public HTTP ports of the compared MZ containers in order to allow running https://optimizer-trace.dev.materialize.com/ against them.

Temporary set the default value to `true` in order to make all of the failing `*.td` tests happy.

frankmcsherry requested a review from a team December 29, 2023 22:16

frankmcsherry force-pushed the equivalence_propagation branch 6 times, most recently from 903d306 to 0f00775 Compare January 2, 2024 21:34

frankmcsherry force-pushed the equivalence_propagation branch 3 times, most recently from da98e1e to b7b45ca Compare February 14, 2024 20:04

frankmcsherry mentioned this pull request Feb 15, 2024

Expression analysis framework #25292

Merged

5 tasks

frankmcsherry force-pushed the equivalence_propagation branch 3 times, most recently from fd8fc76 to e7e33ec Compare February 24, 2024 15:24

frankmcsherry changed the title ~~WIP/DNM: Equivalence propagation~~ Equivalence propagation Feb 26, 2024

frankmcsherry requested review from aalexandrov and ggevay February 26, 2024 13:39

frankmcsherry force-pushed the equivalence_propagation branch from f63ad17 to 779a6d9 Compare February 26, 2024 14:30

frankmcsherry commented Feb 26, 2024

View reviewed changes

src/transform/src/equivalence_propagation.rs Show resolved Hide resolved

frankmcsherry commented Feb 26, 2024

View reviewed changes

test/sqllogictest/transform/predicate_pushdown.slt Outdated Show resolved Hide resolved

ggevay previously requested changes Feb 26, 2024

View reviewed changes

frankmcsherry force-pushed the equivalence_propagation branch 3 times, most recently from 8eac2db to 5aeedfc Compare March 2, 2024 15:19

ggevay reviewed Mar 2, 2024

View reviewed changes

aalexandrov approved these changes Mar 8, 2024

View reviewed changes

frankmcsherry added 7 commits March 8, 2024 21:18

WIP checkin

86fcbed

Rebase onto Analysis prototype

9693d3d

Adopt Analysis ergo idioms

df5eb58

Respond to some (not all) PR feedback

2e39997

Literal errors should not be equated to things

2174680

Do not simplify If::cond expressions

0d69949

Correct bug in TopK::limit simplification

3fe9ef2

aalexandrov force-pushed the equivalence_propagation branch from e36b409 to 35ea714 Compare March 8, 2024 20:01

frankmcsherry requested a review from a team as a code owner March 8, 2024 20:01

frankmcsherry requested review from a team and jkosh44 March 8, 2024 20:01

jkosh44 approved these changes Mar 8, 2024

View reviewed changes

aalexandrov added 9 commits March 8, 2024 22:34

optimizer: update feature flag docs

f186278

optimizer: add enable_equivalence_propagation feature flag

17b7053

sql: add ENABLE EQUIVALENCE PROPAGATION explain flag

7bbe5ea

sql: add ENABLE EQUIVALENCE PROPAGATION cluster feature

fd341f0

transform: wire enable_equivalence_propagation feature flag

0e21dbb

We might want to improve the ergonomics of building a vector of transforms with optional feature flags with a macro.

ci: turn enable_equivalence_propagation on by default

46e95d3

test: fix failing tests

a104e91

transform: fix failing documentation tests

bc4b429

rqg: export public HTTP ports

90575e5

Export the public HTTP ports of the compared MZ containers in order to allow running https://optimizer-trace.dev.materialize.com/ against them.

aalexandrov force-pushed the equivalence_propagation branch from 35ea714 to 90575e5 Compare March 8, 2024 21:01

optimizer: update enable_equivalence_propagation default value

151c0cd

Temporary set the default value to `true` in order to make all of the failing `*.td` tests happy.

aalexandrov enabled auto-merge March 8, 2024 22:09

aalexandrov merged commit 3cfaa82 into MaterializeInc:main Mar 8, 2024
77 checks passed

aalexandrov mentioned this pull request Mar 11, 2024

adapter: save system_parameter_defaults to disk #25924

Closed

5 tasks

aalexandrov mentioned this pull request Apr 24, 2024

sql,optimizer: remove enable_equivalence_propagation #26789

Merged

5 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Equivalence propagation #24155

Equivalence propagation #24155

frankmcsherry commented Dec 29, 2023 •

edited

Loading

ggevay left a comment

ggevay Feb 26, 2024

frankmcsherry Mar 1, 2024

frankmcsherry Mar 1, 2024

ggevay Mar 1, 2024

ggevay Mar 1, 2024

ggevay Feb 26, 2024

ggevay commented Feb 26, 2024

ggevay Mar 2, 2024

ggevay Mar 2, 2024

ggevay Mar 2, 2024

ggevay commented Mar 4, 2024

aalexandrov left a comment •

edited

Loading

aalexandrov Mar 8, 2024

frankmcsherry Mar 8, 2024

shepherdlybot bot commented Mar 8, 2024 •

edited

Loading

jkosh44 left a comment

jkosh44 Mar 8, 2024

aalexandrov Mar 8, 2024

Equivalence propagation #24155

Equivalence propagation #24155

Conversation

frankmcsherry commented Dec 29, 2023 • edited Loading

Motivation

Tips for reviewer

Checklist

ggevay left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ggevay commented Feb 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ggevay commented Mar 4, 2024

aalexandrov left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shepherdlybot bot commented Mar 8, 2024 • edited Loading

Mitigations

jkosh44 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

frankmcsherry commented Dec 29, 2023 •

edited

Loading

aalexandrov left a comment •

edited

Loading

shepherdlybot bot commented Mar 8, 2024 •

edited

Loading