You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
# 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.
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: