Skip to content
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

ACIR: Attach metadata about function inlining #4912

Closed
Tracked by #4877
vezenovm opened this issue Apr 24, 2024 · 1 comment
Closed
Tracked by #4877

ACIR: Attach metadata about function inlining #4912

vezenovm opened this issue Apr 24, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@vezenovm
Copy link
Contributor

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:

enum FunctionMetadata {
   Fold,
   Inline,
}

We then have a couple options on where to place this metadata:

  1. The call opcode itself
  2. 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:

enum FunctionMetadata {
   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

@vezenovm
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Archived in project
Development

No branches or pull requests

1 participant