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
After #4910 we will need the ability to distinguish between non-inlined ACIR functions. Currently every function defaults to that it is not to be inlined. It has been assumed in this case that we have a collection of circuits which are to be folded. The ACVM and/or backend cannot tell what should be inlined if we do not attach some metadata that distinguishes between an ACIR function to be inlined and to be folded.
Happy Case
We should attach some metadata enum somewhere on the ACIR program that indicates whether an ACIR call should be inlined. We would need some meta data struct as such:
enumFunctionMetadata{Fold,Inline,}
We then have a couple options on where to place this metadata:
The call opcode itself
On a circuit struct itself
I lean towards that it would be best on the circuit struct itself. We probably could then generalize recursive flag which exists on the Circuit struct.
Something like this:
enumFunctionMetadata{Fold,Inline,Recursive,Main}
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:
After discussions with @TomAFrench we decided it would be best to keep it that the backend has no knowledge of the circuit type. This simplifies the interface backend's needs to integrate and keeps our mental model of a single circuit for a single proof, and multiple circuits for a folding proof. If we decide we would like to keep circuit artifacts more compact in the future we could re-open this issue and work on handling inlining of circuit artifacts.
Problem
After #4910 we will need the ability to distinguish between non-inlined ACIR functions. Currently every function defaults to that it is not to be inlined. It has been assumed in this case that we have a collection of circuits which are to be folded. The ACVM and/or backend cannot tell what should be inlined if we do not attach some metadata that distinguishes between an ACIR function to be inlined and to be folded.
Happy Case
We should attach some metadata enum somewhere on the ACIR program that indicates whether an ACIR call should be inlined. We would need some meta data struct as such:
We then have a couple options on where to place this metadata:
I lean towards that it would be best on the circuit struct itself. We probably could then generalize
recursive
flag which exists on theCircuit
struct.Something like this:
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: