-
Notifications
You must be signed in to change notification settings - Fork 238
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
Flattening and remove ifelse adds instructions with empty call stacks #5322
Labels
bug
Something isn't working
Comments
5 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 8, 2024
# Description ## Problem\* Resolves #5322 ## Summary\* Previously we added call stacks as a way to give better error reporting on SSA instructions. Since these were just for errors, they only needed to be on instructions which could emit errors. Since then, these call stacks have also been used for profiling Noir code which revealed many instructions without locations - many of them being instructions inserted by the compiler rather than the user during intermediate compiler passes like flatten_cfg. I've went through and gotten rid of each case of `CallStack::new()`. As far as I can tell all the remaining locations are either the intended use case of an initial, empty value, or are used in some error messages where the location is unknown. Anyways - because many of the instructions without locations were not introduced by the user I've had to decide which location best describes them. These instructions are largely internal compiler details so many users would be surprised if they knew e.g. we inserted extra `Store` instructions to _undo_ previous store instructions when going between an if expression's then and else branches. In this case, I set the location of this undo store instruction the same as the original store, but an argument could be made that it should actually be in the else branch or share location with the whole if expression. Similarly, when an `if` expression is used we merge the return value of the then & else branches to get the return value of the `if` expression itself. For these values I've opted to use the location of the entire `if` expression. ## Additional Context @vezenovm I think this covers all the work needed for this issue after all. ## 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.
github-merge-queue bot
pushed a commit
that referenced
this issue
Aug 8, 2024
# Description ## Problem\* Resolves #5322 ## Summary\* Previously we added call stacks as a way to give better error reporting on SSA instructions. Since these were just for errors, they only needed to be on instructions which could emit errors. Since then, these call stacks have also been used for profiling Noir code which revealed many instructions without locations - many of them being instructions inserted by the compiler rather than the user during intermediate compiler passes like flatten_cfg. I've went through and gotten rid of each case of `CallStack::new()`. As far as I can tell all the remaining locations are either the intended use case of an initial, empty value, or are used in some error messages where the location is unknown. Anyways - because many of the instructions without locations were not introduced by the user I've had to decide which location best describes them. These instructions are largely internal compiler details so many users would be surprised if they knew e.g. we inserted extra `Store` instructions to _undo_ previous store instructions when going between an if expression's then and else branches. In this case, I set the location of this undo store instruction the same as the original store, but an argument could be made that it should actually be in the else branch or share location with the whole if expression. Similarly, when an `if` expression is used we merge the return value of the then & else branches to get the return value of the `if` expression itself. For these values I've opted to use the location of the entire `if` expression. ## Additional Context @vezenovm I think this covers all the work needed for this issue after all. ## 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Aim
Profiling where all the constraints in the program come from
Expected Behavior
Every ACIR opcode should have a call stack associated with it
Bug
Some ACIR opcodes in the program have no call stack associated. I've added a condition in the SSA printer to figure out wich instructions in SSA do not have any call stack associated.
I've tracked down these instructions to some optimization steps:
flatten_cfg.rs
: Explicitely usesCallStack::new()
for instructions related with the if condition. A solution to this might be to add call_stack to JmpIf in the same way Jmp and Return have call stacks, to associated the emitted instructions with.value_merger.rs::merge_numeric_values
: This seems to be emitting some Cast and mul instructions with no call stack associated, because sometimes the if value and the else value have no call stack associated. I guess this can happen when the if else values don't come from previous instructions, such as being block params or constantsremove_if_else.rs
: Seems to be emitting array_get instructions with no call_stack, presumably fromvalue_merger::merge_array_values
that has a explicitCallStack::new()
when emitting an ArrayGetIn the case we can't track down the instructions to a specific location instruction, it'd be good to at least use the call stack of the function being processed, allowing users to at least track that the instruction comes from a given function call, even though they might not know which part of the function being called generated it 🤔
To Reproduce
Modify this code in printer.rs
And compile a large program such as aztec protocol circuits or the token contract transfer function with show ssa enabled.
Project Impact
None
Impact Context
No response
Workaround
None
Workaround Description
No response
Additional Context
No response
Installation Method
None
Nargo Version
No response
NoirJS Version
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response
The text was updated successfully, but these errors were encountered: