Add handling for no_predicates functions
#4911
Labels
Comments
vezenovm
changed the title
#[inline(never)] functions
5 tasks
vezenovm
changed the title
#[inline(never)] functions no_predicates functions
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 30, 2024
# Description ## Problem\* Resolves #4911 and #4688 ## Summary\* ~~We recently included the `#[inline(never)]` attribute to enable developers to optimize codegen.~~ This has now been switched to the name `no_predicates`. The main use-case in mind is for circuits in issue #4688 where inlining a function with heavy array operations when dependent upon witnesses is not always ideal. Specifically when the function being inlined does not need to rely on the predicate for correctness. Originally I had in mind to delay inlining all the way to after ACIR gen and inline the ACIR artifacts. However, this feels overly complex now as we have all the infrastructure to inline functions as we wish during SSA, we could just need to delay the inlining of certain functions to happen after flattening. This PR does exactly what was just mentioned. For example, the new test `no_predicates_numeric_generic_poseidon` gave these results when `poseidon_hash` was not marked with `#[no_predicates_numeric_generic_poseidon]`: <img width="785" alt="ExistingInlineStrategy" src="https://github.com/noir-lang/noir/assets/43554004/f2fc1358-c86c-4f02-999e-414056b87a01"> While when `poseidon_hash` was marked with `#[no_predicates_numeric_generic_poseidon]`: <img width="788" alt="InlineNeverBench" src="https://github.com/noir-lang/noir/assets/43554004/21d729f9-32db-4a32-b592-56f76bf5663d"> ## Additional Context ## Documentation\* Check one: - [ ] No documentation needed. - [ ] Documentation included in this PR. - [X] **[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
Problem
As per the description in #4877 we want to be able to defer inlining during code generation but we still want to send a single circuit to the backend for proving/verification.
Happy Case
We want to add support for an inlining tool in ACVM so that each backend does not have to rely on writing its own inlining logic. This would be blocked by this issue (#4912) as we need some way to tell which circuit should be inlined and which should not.We should go for an initial solution that does not require changing the ACIR or ACVM artifacts. We can have
#[no_predicates]as an SSA gen exclusive codegen attribute. We can instead just using SSA inlining to inline following the passes which cause a blow-up in circuit size(flattening the cfg).#[no_predicates]is really now "skip the first function inlining and inline only after flattening".Perhaps in the future we can go back to inlining the ACIR artifacts themselves, but for now any inline attributes will be exclusive to the SSA process.
Project Impact
Blocker
Impact Context
No response
Workaround
None
Workaround Description
No response
Additional Context
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: