-
Notifications
You must be signed in to change notification settings - Fork 206
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
fix(ssa): Tracking slices stores correctly for parent blocks and handling in ACIR #4221
Conversation
In this PR for merging nested slices #3979 the slice capacity tracker that was written for the fill internal slices pass was used by the flattening pass to track slice capacities. This let us remove the back tracking done by the So, I am converting this PR back to a draft. I wanted to bring back the capacity tracker anyway to remove EDIT: Going to do the capacity_tracker in a followup to this PR. It turns out this bug required two fixes. One for accurately tracking slices in parent blocks which could be done with the simple bandaid in this PR, and then ACIR updates outlined in the main PR description. |
…nition (#4221) Resolves #4222 Currently in order to specify whether we want to use a prover that produces SNARK recursion friendly proofs, we must pass a flag from the tooling infrastructure. This PR moves it be part of the circuit definition itself. The flag now lives on the Builder and is set when we call `create_circuit` in the acir format. The proof produced when this flag is true should be friendly for recursive verification inside of another SNARK. For example, a recursive friendly proof may use Blake3Pedersen for hashing in its transcript, while we still want a prove that uses Keccak for its transcript in order to be able to verify SNARKs on Ethereum. However, a verifier does not need a full circuit description and should be able to verify a proof with just the verification key and the proof. An `is_recursive_circuit` field was thus added to the verification key as well so that we can specify the accurate verifier to use for a given proof without the full circuit description. --------- Signed-off-by: kevaundray <[email protected]> Co-authored-by: ledwards2225 <[email protected]> Co-authored-by: kevaundray <[email protected]>
Have one more idea I want to try out to avoid the ACIR changes so converting back to a draft temporarily. |
I was able to resolve this by fixing up #4240 and making a truly accurate slice capacity tracker. Closing this PR. |
Description
Problem*
Resolves #4202
Summary*
There are two fixes done in this PR, one in the SSA and one in the ACIR:
SSA Update
When storing slice stores from the outer block we were only checking
JmpIf
terminators. The issue has provided an example SSA where we jump to a block which performs a jump if without the block with the jump if storing any values.Here is the SSA for the basic failing program in the linked issue:
We now just check blocks with jump terminators for stores as well.
ACIR Update
After the flattening pass, the following mem2reg pass may resolve a constant array into the
array_get
that gets inserted inside ofmerge_slice_values
. This constant array can potentially be smaller than the constant index that gets specified during flattening if we are merging slices of two different sizes.Inside ACIR when handling constant indices we now allow returning dummy data when we have a constant index that is greater than the array size. This should be safe to do as any slice accesses specified by the user will always codegen a check against the dynamic slice length. The only time we will have a raw array get for a slice like this is due to instructions inserted by the compiler such as with flattening.
Additional Context
Documentation*
Check one:
PR Checklist*
cargo fmt
on default settings.