-
Notifications
You must be signed in to change notification settings - Fork 219
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: Handle multiple entry points for Brillig call stack resolution a…
…fter metadata deduplication (#5788) # Description ## Problem\* Resolves <!-- Link to GitHub Issue --> Issue created by #5696. ## Summary\* After the creation of the brillig locations map in #5696. we do the following to attach Brillig locations to our generated acir: ```rust if inserted_func_before { return; } for (brillig_index, call_stack) in generated_brillig.locations.iter() { self.brillig_locations.entry(brillig_function_index).or_default().insert( OpcodeLocation::Brillig { acir_index: self.opcodes.len() - 1, brillig_index: *brillig_index, }, call_stack.clone(), ); } ``` This inserts the ACIR index at the location the brillig call was pushed. However, this is only valid for the first Brillig call. Any later Brillig calls will also use this acir index to resolve against the debug metadata. We just need to avoid trying to match against this acir index as the Brillig call stacks do not require the acir index in order to be resolved against the debug metadata. I also fixed the flamegraph in this PR. For the following snippet where x == 0 causing a failure: ```rust fn main(x: Field) { unsafe { assert(1 == conditional_wrapper(!x as bool)); assert(1 == conditional_wrapper(x as bool)); } } unconstrained fn conditional_wrapper(x: bool) -> Field { conditional(x) } unconstrained fn conditional(x: bool) -> Field { assert(x); 1 } ``` Before: <img width="840" alt="Screenshot 2024-08-21 at 11 45 45 PM" src="https://github.com/user-attachments/assets/532f218a-9c24-434d-8760-e9bfe6859c01"> After: <img width="838" alt="Screenshot 2024-08-21 at 11 47 17 PM" src="https://github.com/user-attachments/assets/82d5d690-3133-4d1e-9818-4f49de2f55d0"> The flame graph also is operating as expected now. Here some example output from one of the Brillig entry point of the `brillig_calls` test: <img width="1590" alt="Screenshot 2024-08-21 at 11 48 01 PM" src="https://github.com/user-attachments/assets/1a840bda-0b8d-4233-88c2-a317bd88cc1e"> ## Additional Context The assert messages still use the `Brillig` variant of `OpcodeLocation`. This is a breaking serialization change so I have opted for not changing that here and making a separate struct type for Brillig opcode locations. ## Documentation\* Check one: - [X] No documentation needed. - [ ] Documentation included in this PR. - [ ] **[For Experimental Features]** Documentation to be submitted in a separate PR. # PR Checklist\* - [X] I have tested the changes locally. - [X] I have formatted the changes with [Prettier](https://prettier.io/) and/or `cargo fmt` on default settings.
- Loading branch information
Showing
8 changed files
with
98 additions
and
29 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters