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

Combine mload_32bytes and mstore_32bytes flags #1252

Closed

Conversation

LindaGuiga
Copy link
Contributor

This PR combines the two flags: mload_32bytes and mstore_32bytes, as well as the two associated CTLs.
This required changing the order of the stack for MSTORE_32BYTES.

@nbgl nbgl self-requested a review October 18, 2023 21:21
@Nashtare Nashtare added the optimization Performance related changes label Oct 23, 2023
Copy link
Contributor

@nbgl nbgl left a comment

Choose a reason for hiding this comment

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

Looks good, just a few nits. Thank you :)

pushes: true,
disable_other_channels: false,
}),
memop_32bytes: None,
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd add a comment to say where these constraints do live (if only to make clear that they haven't been forgotten).

Comment on lines 43 to 46
global mstore_unpacking:
// stack: context, segment, offset, value, len, retdest
%stack(context, segment, offset, value, len, retdest) -> (context, segment, offset, value, len, offset, len, retdest)
// stack: context, segment, offset, value, len, offset, len, retdest
%stack(context, segment, offset, value, len, retdest) -> (context, segment, offset, len, value, offset, len, retdest)
// stack: context, segment, offset, len, value, offset, len, retdest
Copy link
Contributor

Choose a reason for hiding this comment

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

This makes the argument order of mstore_unpacking inconsistent with MSTORE_32BYTES. I worry that it could become confusing.

In how many places is mstore_unpacking used? Would it be a lot of work to fix the argument order in those places as well?

Comment on lines +128 to 130
pub fn ctl_data_byte32<F: Field>() -> Vec<Column<F>> {
ctl_data_keccak_sponge()
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: as we're re-using ctl_data_keccak_sponge both for MLOAD_32BYTES and MSTORE_32BYTES, perhaps a tiny comment explaining the distinction may be useful? (as the doc there is valid for MLOAD but the last memory channel is being read in the case of MSTORE, not pushed to).

Copy link

sonarcloud bot commented Nov 9, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@LindaGuiga
Copy link
Contributor Author

Given all the changes introduced recently, it seems impossible (for now at least) to merge the two flags given the current state of things. Indeed, removing one memory channel implied changing the CTL for mstore_32bytes, and makes it different from mload_32bytes (in mstore_32bytes, we set the length in the CTL by computing next_value - current_offset, and we can't do that in mload_32bytes since we just want to check that the loaded value is correct). I am therefore closing this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
optimization Performance related changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants