Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use ast::Value equivalence, not enum equality, to do constant folding of constants #12518

Merged
merged 6 commits into from
Mar 15, 2024

Conversation

brmataptos
Copy link
Contributor

@brmataptos brmataptos commented Mar 13, 2024

Description

Fixes issue #12516 by using ast::Value equivalence
(newly exposed through function Value::equivalent()),
rather than struct
equality, when constant-folding equality operations.
(Value::ByteArray(..) and Value::AddressArray(..) values can
each also be represented by Value::Vector(..) instead).

This fixes a failure that shows up in 0x1::ristretto:255
test case test_scalar_from_canonical_bytes.

Fixes #12516.

Type of Change

  • New feature
  • Bug fix
  • Breaking change
  • Performance improvement
  • Refactoring
  • Dependency update
  • Documentation update

Which Components or Systems Does This Change Impact?

  • Validator Node
  • Full Node (API, Indexer, etc.)
  • Move/Aptos Virtual Machine
  • Aptos Framework
  • Aptos CLI/SDK
  • Developer Infrastructure
  • Other (specify)
    V2 compiler

How Has This Been Tested?

Included thorough unit test for new function Value::equivalent,
and a targeted test case constant_folding_ristretto.move for
comparison with V1 and V2 without simplification.

Existing V2 CI tests should show the original problem is fixed.

Key Areas to Review

Consider redundancy and ambiguity of the AST representation, perhaps there are more cases.

Checklist

  • I have read and followed the CONTRIBUTING doc
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I identified and added all stakeholders and component owners affected by this change as reviewers
  • I tested both happy and unhappy path of the functionality
  • I have made corresponding changes to the documentation

Copy link

trunk-io bot commented Mar 13, 2024

⏱️ 20h 39m total CI duration on this PR
Job Cumulative Duration Recent Runs
rust-unit-tests 3h 45m 🟩🟩🟩🟩 (+6 more)
windows-build 2h 39m 🟩🟩🟩🟩🟩 (+5 more)
rust-move-tests 2h 25m 🟩🟩🟩🟩🟩 (+3 more)
rust-smoke-tests 2h 6m 🟩🟩🟩🟩
rust-move-unit-coverage 1h 57m 🟩🟩🟩🟩🟩 (+3 more)
execution-performance / single-node-performance 1h 17m 🟩🟩🟥🟩
rust-lints 1h 3m 🟩🟩🟩🟩 (+5 more)
rust-images / rust-all 58m 🟩🟩🟩🟩
forge-e2e-test / forge 57m 🟩🟩🟩🟩
forge-compat-test / forge 57m 🟩🟩🟩🟩
check 40m 🟩🟩🟩🟩 (+5 more)
run-tests-main-branch 34m 🟥🟥🟥🟥 (+5 more)
cli-e2e-tests / run-cli-tests 29m 🟩🟩🟩🟩
general-lints 21m 🟩🟩🟩🟩🟩 (+5 more)
check-dynamic-deps 18m 🟩🟩🟩🟩🟩 (+5 more)
semgrep/ci 4m 🟩🟩🟩🟩🟩 (+5 more)
node-api-compatibility-tests / node-api-compatibility-tests 3m 🟩🟩🟩🟩
file_change_determinator 2m 🟩🟩🟩🟩🟩 (+5 more)
file_change_determinator 2m 🟩🟩🟩🟩🟩 (+5 more)
file_change_determinator 42s 🟩🟩🟩🟩
permission-check 38s 🟩🟩🟩🟩🟩 (+5 more)
execution-performance / file_change_determinator 37s 🟩🟩🟩🟩
permission-check 34s 🟩🟩🟩🟩🟩 (+5 more)
permission-check 33s 🟩🟩🟩🟩🟩 (+5 more)
permission-check 28s 🟩🟩🟩🟩🟩 (+5 more)
determine-docker-build-metadata 14s 🟩🟩🟩🟩
permission-check 13s 🟩🟩🟩🟩

🚨 1 job on the last run was significantly faster/slower than expected

Job Duration vs 7d avg Delta
windows-build 12m 20m -37%

settingsfeedbackdocs ⋅ learn more about trunk.io

@brmataptos brmataptos requested review from vineethk and wrwg March 13, 2024 23:24
Copy link
Contributor

@vineethk vineethk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added a comment to double check a scenario - it may or may not be an issue. If you think it is safe, then this is good to go.

if x.len() == y.len() {
iter::zip(x, y).all(|(value, addr)| {
if let Value::Address(addr1) = value {
addr1 == addr
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double check if this == is okay (i.e., could there be cases where Addresses are the same at runtime even though they are represented by different enums - that is, "numeric vs. symbolic" and "symbolic vs. symbolic where the symbols are different but resolved to the same address").

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. I'll change it to make that case incomparable and not constant.

@brmataptos brmataptos requested a review from vineethk March 14, 2024 06:03
@brmataptos
Copy link
Contributor Author

I changed ast::Value::equivalent to a partial function (returns Option<bool>) to allow constant folding to avoid folding cases where symbolic addresses make the value of the test unknown. Not sure if those can actually arise, but it seems good to be safe. I don't know how to test that case in the constant folder, but I have very very thorough tests of ast::Value::equivalent that helped make it correct, if a bit verbose.

PTAL

Copy link

codecov bot commented Mar 14, 2024

Codecov Report

Attention: Patch coverage is 99.19355% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 63.9%. Comparing base (7a0d32b) to head (642f467).
Report is 2 commits behind head on main.

Files Patch % Lines
third_party/move/move-model/src/ast.rs 99.1% 2 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff            @@
##             main   #12518    +/-   ##
========================================
  Coverage    63.9%    63.9%            
========================================
  Files         816      816            
  Lines      180680   180914   +234     
========================================
+ Hits       115548   115783   +235     
+ Misses      65132    65131     -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

/// implement the same runtime value, assuming that types match.
///
/// If `Address` values are symbolic and differ, then no answer can be given.
pub fn equivalent(&self, other: &Value) -> Option<bool> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appreciate such cleanly written code, makes it easy to reason about.

@@ -2993,3 +3091,183 @@ impl<'a> fmt::Display for EnvDisplay<'a, Spec> {
Ok(())
}
}

#[test]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: it is more idiomatic (and helpful in the presence of further changes and maintainance) to wrap all this with:

#[cfg(test)]
mod tests {
    // code to be wrapped
}

Source: https://doc.rust-lang.org/book/ch11-01-writing-tests.html#the-anatomy-of-a-test-function

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found I had to add several use statements as well, then I read that page and saw an example using use super::*;, but after I pushed my new code. I suppose explicit use statements provides guidance to users of the code.

@lightmark lightmark enabled auto-merge (squash) March 14, 2024 21:02

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

@brmataptos brmataptos force-pushed the brm-issue-10850-fix branch from d7e29ab to ec22f03 Compare March 15, 2024 00:20

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

@brmataptos brmataptos disabled auto-merge March 15, 2024 00:54
@brmataptos
Copy link
Contributor Author

Symbolic Address inequality does not imply that Addresses are really different at runtime.

@brmataptos brmataptos enabled auto-merge (squash) March 15, 2024 02:15

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

@brmataptos brmataptos force-pushed the brm-issue-10850-fix branch from 7d09e1b to 642f467 Compare March 15, 2024 02:51

This comment has been minimized.

This comment has been minimized.

Copy link
Contributor

✅ Forge suite realistic_env_max_load success on 642f4673ad163b5b93fbd6171af08339d051ff7d

two traffics test: inner traffic : committed: 7825 txn/s, latency: 5008 ms, (p50: 4800 ms, p90: 6000 ms, p99: 10200 ms), latency samples: 3380540
two traffics test : committed: 100 txn/s, latency: 1826 ms, (p50: 1800 ms, p90: 2000 ms, p99: 2300 ms), latency samples: 1780
Latency breakdown for phase 0: ["QsBatchToPos: max: 0.241, avg: 0.206", "QsPosToProposal: max: 0.286, avg: 0.258", "ConsensusProposalToOrdered: max: 0.486, avg: 0.430", "ConsensusOrderedToCommit: max: 0.310, avg: 0.293", "ConsensusProposalToCommit: max: 0.741, avg: 0.723"]
Max round gap was 1 [limit 4] at version 1615386. Max no progress secs was 4.525066 [limit 15] at version 1615386.
Test Ok

Copy link
Contributor

✅ Forge suite compat success on aptos-node-v1.9.5 ==> 642f4673ad163b5b93fbd6171af08339d051ff7d

Compatibility test results for aptos-node-v1.9.5 ==> 642f4673ad163b5b93fbd6171af08339d051ff7d (PR)
1. Check liveness of validators at old version: aptos-node-v1.9.5
compatibility::simple-validator-upgrade::liveness-check : committed: 7060 txn/s, latency: 4689 ms, (p50: 5000 ms, p90: 6000 ms, p99: 7400 ms), latency samples: 247100
2. Upgrading first Validator to new version: 642f4673ad163b5b93fbd6171af08339d051ff7d
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 1714 txn/s, latency: 17284 ms, (p50: 19000 ms, p90: 22300 ms, p99: 23500 ms), latency samples: 80600
3. Upgrading rest of first batch to new version: 642f4673ad163b5b93fbd6171af08339d051ff7d
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 250 txn/s, submitted: 593 txn/s, expired: 342 txn/s, latency: 38124 ms, (p50: 42200 ms, p90: 50100 ms, p99: 57100 ms), latency samples: 19041
4. upgrading second batch to new version: 642f4673ad163b5b93fbd6171af08339d051ff7d
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 2370 txn/s, latency: 11929 ms, (p50: 12100 ms, p90: 16500 ms, p99: 18100 ms), latency samples: 113800
5. check swarm health
Compatibility test for aptos-node-v1.9.5 ==> 642f4673ad163b5b93fbd6171af08339d051ff7d passed
Test Ok

@brmataptos brmataptos merged commit 1b43e0e into main Mar 15, 2024
47 checks passed
@brmataptos brmataptos deleted the brm-issue-10850-fix branch March 15, 2024 03:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug][move-compiler-v2] AST Simplifier causes a test failure with V2 on aptos stdlibs
3 participants