-
Notifications
You must be signed in to change notification settings - Fork 298
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
Store top of the stack in memory channel 0 #1215
Store top of the stack in memory channel 0 #1215
Conversation
Some figures about the memory trace reduction:
(on a slightly outdated branch but still relevant) |
Failures are from interpreter tests, since I forgot to update the top_stack logic there, but other integration tests pass. I'm working on fixing this. |
@wborgeaud |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not an actual review, just quickly skimmed through. Only the comment on decode.rs matters though, the rest is nitpicking cleanup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is excellent work!! Thank you.
I'm sorry it took me so long to review this.
Thanks for the review! We're not merging right now since we found some tests from the EVM test suite which aren't passing. |
Updated version of #1196. This one only introduces one extra column (by reintroducing the
get_context
andset_context
flag).This PR stores the current top of the stack in memory channel 0, saving memory operations in a lot of cases.
Reading and writing the new top of the stack after an operation is straightforward, but the most annoying thing was a disjunction depending on whether the current stack was empty or not for pushing instructions (resp. the next stack was empty or not for popping instructions), and whether or not to disable a channel in that case. This was done with prover-provided inverses which could be stored in general CPU columns, thus not adding any new columns.
Further work:
I couldn't get to mix this PR with the column merging while keeping stack constraint degrees below 3. I have an inkling this should be possible with more general columns though.
closes #1149