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 part of the initial work to add non-inlined ACIR #4428 we added type checking that treated all inputs to entry point ACIR the same. This meant non-inlined ACIR functions which were not main would have the same restriction of only support what is supported in Noir's ABI. This is an unnecessary restriction.
Happy Case
We should support more compile-time inputs for non-inlined ACIR entry points. For example, numeric generics should be known at compile-time for non-inlined ACIR.
References will still have to be restricted. We would only be able to pass references as inputs if we started to support them in ACIR gen. Slice sizes are technically known at compile time, but not during monomorphization when we have slices whose size is dependent upon witness conditions. For now, we just want to upgrade numeric generics.
Project Impact
Blocker
Impact Context
This prevents being able to not inline functions which utilize numeric generics, such as our poseidon2 hash method:
# Description
## Problem\*
Resolves#4826.
## Summary\*
When running `nargo info` with the following code:
```rust
use dep::std::hash::{pedersen_hash_with_separator, poseidon2::Poseidon2};
global NUM_HASHES = 2;
global HASH_LENGTH = 10;
#[fold]
pub fn poseidon_hash<N>(inputs: [Field; N]) -> Field {
Poseidon2::hash(inputs, inputs.len())
}
fn main(
to_hash: [[Field; HASH_LENGTH]; NUM_HASHES],
enable: [bool; NUM_HASHES]
) -> pub [Field; NUM_HASHES] {
let mut result = [0; NUM_HASHES];
for i in 0..NUM_HASHES {
let enable = enable[i];
let to_hash = to_hash[i];
if enable {
result[i] = poseidon_hash(to_hash);
}
}
result
}
```
<img width="739" alt="Screenshot 2024-04-17 at 3 46 54 PM"
src="https://github.com/noir-lang/noir/assets/43554004/fa31977d-96e9-45f7-8001-43865bc4a83c">
When using `pedersen_hash` we also get 10 opcodes for `main`.
Once we get more granularity in our inline types (fold vs. inline for
proving) we can most likely fully resolve this issue
(#4688).
## Additional Context
## Documentation\*
Check one:
- [ ] No documentation needed.
- [ ] Documentation included in this PR.
- [ ] **[For Experimental Features]** Documentation to be submitted in a
separate PR.
# PR Checklist\*
- [ ] I have tested the changes locally.
- [ ] I have formatted the changes with [Prettier](https://prettier.io/)
and/or `cargo fmt` on default settings.
Problem
As part of the initial work to add non-inlined ACIR #4428 we added type checking that treated all inputs to entry point ACIR the same. This meant non-inlined ACIR functions which were not
main
would have the same restriction of only support what is supported in Noir's ABI. This is an unnecessary restriction.Happy Case
We should support more compile-time inputs for non-inlined ACIR entry points. For example, numeric generics should be known at compile-time for non-inlined ACIR.
References will still have to be restricted. We would only be able to pass references as inputs if we started to support them in ACIR gen. Slice sizes are technically known at compile time, but not during monomorphization when we have slices whose size is dependent upon witness conditions. For now, we just want to upgrade numeric generics.
Project Impact
Blocker
Impact Context
This prevents being able to not inline functions which utilize numeric generics, such as our poseidon2 hash method:
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: