-
Notifications
You must be signed in to change notification settings - Fork 221
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
feat(ssa): Immediately simplify away RefCount instructions in ACIR functions #6893
Conversation
Peak Memory Sample
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far!
Compilation Report
|
Execution Report
|
Execution Memory Report
|
Compilation Memory Report
|
I think we should merge #6894 before this as we can then remove the runtime separation changes in this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Co-authored-by: Maxim Vezenov <[email protected]>
This reverts commit 694e27c.
if !self.is_handled_by_runtime(&instruction) { | ||
return InsertInstructionResult::InstructionRemoved; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check shouldn't be needed anymore since #6894 already prevents inc/dec rc from being inserted into acir functions. They'd only be able to be reintroduced via at inlining optimization pass which inlines brillig code into an acir function, but that shouldn't be possible anyway.
Perhaps we'll have more brillig-only instructions in the future though? (e.g. separating array semantics)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also (unrelated), with runtime in the dfg now... do we really need both dfg and Function? Function now is just a wrapper around a dfg and an entry block, id, and name. IIRC we copied this from cranelift originally but I'm unsure of the motivation there. Perhaps Function had more fields. Maybe we want to avoid polluting the already large dfg with these extra fields though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah that's true. I didn't notice the circuit diff disappearing from this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw a runtime check added here, but AFAICS constant_folding and loop_invariant can still add them directly.
FWIW if I return true
from is_handled_by_runtime
then we get the following integration test failures because of the panic "Expected all Rc instructions to be removed before acir_gen":
tests::execution_success::test_6::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_array_dynamic_blackbox_input::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_array_to_slice::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_bigint::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_brillig_identity_function::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_conditional_regression_short_circuit::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_debug_logs::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_hashmap::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_hint_black_box::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_merkle_insert::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_nested_array_dynamic::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_pedersen_check::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_pedersen_hash::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_regression_4449::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_sha256::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_sha256_regression::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_sha256_var_padding_regression::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_sha256_var_size_regression::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_sha256_var_witness_const_regression::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_sha2_byte::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_simple_shield::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_slice_dynamic_index::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_slice_regex::forcebrillig_false_inliner_i64_min_expects
tests::execution_success::test_slices::forcebrillig_false_inliner_i64_min_expects
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw a runtime check added here, but AFAICS constant_folding and loop_invariant can still add them directly.
We probably just need to have similar runtime checks in those passes which add the rc instructions directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if we add the checks in the passes directly then we can roll back this entire PR. Adding them in the passes might be the only option if the runtime-specific pattern is more complicated than an individual instruction.
I did it this way because:
- the ticket suggested there is value in not having instructions which will be just ignored later on, and
- I thought that the passes that added them could have always been written with these checks included, so if they weren't, maybe the intention was to keep them agnostic, or at least not more complicated.
It seemed like silently skipping such instructions was the lightest touch, but I see the value in handling them in the passes as well, saving the extra checks for every instruction that is added.
…oir#6926) chore: simplify boolean in a mul of a mul (noir-lang/noir#6951) feat(ssa): Immediately simplify away RefCount instructions in ACIR functions (noir-lang/noir#6893) chore: Move comment as part of #6945 (noir-lang/noir#6959) chore: Separate unconstrained functions during monomorphization (noir-lang/noir#6894) feat!: turn CannotReexportItemWithLessVisibility into an error (noir-lang/noir#6952) feat: lock on Nargo.toml on several nargo commands (noir-lang/noir#6941) feat: don't simplify SSA instructions when creating them from a string (noir-lang/noir#6948) chore: add reproduction case for bignum test failure (noir-lang/noir#6464) chore: bump `noir-gates-diff` (noir-lang/noir#6949) feat(test): Enable the test fuzzer for Wasm (noir-lang/noir#6835) chore: also print test output to stdout in CI (noir-lang/noir#6930) fix: Non-determinism from under constrained checks (noir-lang/noir#6945) chore: use logs for benchmarking (noir-lang/noir#6911) chore: bump `noir-gates-diff` (noir-lang/noir#6944) chore: bump `noir-gates-diff` (noir-lang/noir#6943) fix: Show output of `test_program_is_idempotent` on failure (noir-lang/noir#6942) chore: delete a bunch of dead code from `noirc_evaluator` (noir-lang/noir#6939) feat: require trait function calls (`Foo::bar()`) to have the trait in scope (imported) (noir-lang/noir#6882) chore: Bump arkworks to version `0.5.0` (noir-lang/noir#6871)
chore: simplify boolean in a mul of a mul (noir-lang/noir#6951) feat(ssa): Immediately simplify away RefCount instructions in ACIR functions (noir-lang/noir#6893) chore: Move comment as part of #6945 (noir-lang/noir#6959) chore: Separate unconstrained functions during monomorphization (noir-lang/noir#6894) feat!: turn CannotReexportItemWithLessVisibility into an error (noir-lang/noir#6952) feat: lock on Nargo.toml on several nargo commands (noir-lang/noir#6941) feat: don't simplify SSA instructions when creating them from a string (noir-lang/noir#6948) chore: add reproduction case for bignum test failure (noir-lang/noir#6464) chore: bump `noir-gates-diff` (noir-lang/noir#6949) feat(test): Enable the test fuzzer for Wasm (noir-lang/noir#6835) chore: also print test output to stdout in CI (noir-lang/noir#6930) fix: Non-determinism from under constrained checks (noir-lang/noir#6945) chore: use logs for benchmarking (noir-lang/noir#6911) chore: bump `noir-gates-diff` (noir-lang/noir#6944) chore: bump `noir-gates-diff` (noir-lang/noir#6943) fix: Show output of `test_program_is_idempotent` on failure (noir-lang/noir#6942) chore: delete a bunch of dead code from `noirc_evaluator` (noir-lang/noir#6939) feat: require trait function calls (`Foo::bar()`) to have the trait in scope (imported) (noir-lang/noir#6882) chore: Bump arkworks to version `0.5.0` (noir-lang/noir#6871)
Description
Problem*
Resolves #6831
Summary*
Assuming the runtime separation has already happened, prevents
IncrementRc
andDecrementRc
from being added to ACIR functions by moving theruntime
field from theFunction
to theDataFlowGrap
, and modifyinginsert_instruction_and_results
to immediately returnInstructionRemoved
if theInstruction
would not be handled by the current runtime. This is to prevent e.g.constant_folding
andloop_invariants
to re-introduce these instructions, and so that we don't constantly have to keep it in mind that we should add them only in one runtime, but not the other.Additional Context
Documentation*
Check one:
PR Checklist*
cargo fmt
on default settings.