fix: Fix poor handling of aliased references in flattening pass causing some values to be zeroed

[jfecher]

Description

Problem*

Resolves #5771

Summary*

Background

Fixes a bug which originates from merge_stores in the flattening pass which can in certain cases get confused with aliases and overwrite values incorrectly.

The rough steps to reproduce this issue are as follows, though I've been unsuccessful so far in reproducing it from scratch outside of the original branch in aztec packages.

1. Create a mutable reference to something, for example an integer (context.side_effect_counter in the original bug)
2. Use a runtime conditional if input_to_main { ... }, and ensure that input_to_main = false
3. Within the conditional try to confuse the compiler by creating a mutable alias to the reference in a way that the alias only appears after the first mem2reg pass and before the flattening pass. In this case, using an immediately-invoked closure which captures the reference as part of its environment.
4. Use some oracles or other functions which can't be inlined/evaluated currently within that closure.
5. Create another nested if within the closure, also using a runtime condition
6. Inside that if, conditionally mutate the captured reference.
7. Back to the first if, after the closure is invoked, at the end of the if, mutate the original, non-captured reference.

This somewhat specific setup lead to a situation where the flattening pass saw it had a store to what it saw as two different references, but were really both aliases to the same reference. merge_stores uses a then_value, else_value, and old_value of each reference to create its new_value which it then stores back to the reference. One alias in this case had a correct then_value, while the other had a correct else_value, with the opposite value of both being equal to the old_value. Storing both of these in sequence lead to the final value for the else/false case to be !input_to_main * (input_to_main * else_value). Since one of input_to_main and its negation are always zero, the whole value ends up zeroed for the else case. Finally, confusion with aliases also leads the compiler to accept the else case value as the updated value even after the if terminates.

I've been unsuccessful trying to reproduce this from scratch so come Monday I'll work on copying over the same test case into an integration test here. I've already removed all macro code but need to figure out how to translate the oracle functions step mainly.

The Fix

Skipping some alternate fixes I tried, I figured out we could just remove merge_stores entirely if we never stored a non-conditional value to a reference to begin with during flattening. E.g. currently in flattening if we see if c { foo = 3; } we issue a store 3 in foo then after the if we go back and merge stores to issue a store (if c then 3 else prev_value) in foo afterward. I've changed it to instead issue prev_value = load foo; store (if c then 3 else prev_value) in foo to replace the original store. This means the value of a reference is always correct and we never have to fix it afterward. This greatly simplifies the flattening pass I think.

HOWEVER:

• The first store to an allocation has no previous value: foo = allocate; store 3 in foo, so I had to add an initial_value: ValueId argument to the Allocate instruction.
  • Not requiring an initial store breaks the mem2reg pass... In particular the logic to remove the last store is breaking. For this reason I'll probably try to revert the Allocate argument change in favor of a hack to not insert a previous value load if allocate is the instruction previous to the current store since we always issue them one after another in practice.
• Issuing an Instruction::IfElse for every store leads to more value merging in practice, resulting in increase constraint counts without something like feat: avoid branch condition negations in ValueMerger #6073.

Additional Context

Draft because I had to port this over from local changes within aztec packages (branch jf/fix-zeroed-bug) and there are a few merges that still need to be handled carefully - most notably the mem2reg changes.

Remaining work

• Reproduce test
• Revert Instruction::Allocate changes in favor of hack
• Fix remaining merge diffs from this PR since it was ported from aztec-packages

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 and/or cargo fmt on default settings.

[jfecher]

The size of this draft looks large but the actual changes are fairly small and it is mostly removed code. Most of the code size changes are due to merge diffs and the Instruction::Allocate change I'll revert. Fixed

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: e4e3815ce910ab2dd7f38541349a5edf9190b565, compared to commit: 852c87ae9ecdd441ee4c2ab3e78e86b2da07d8a4

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
tuples	+16 ❌	+43.24%
brillig_slices	+184 ❌	+34.59%
closures_mut_ref	+7 ❌	+30.43%
missing_closure_env	+3 ❌	+13.64%
regression_6451	+4 ❌	+9.09%
references	+25 ❌	+8.62%
1_mul	+5 ❌	+8.06%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
tuples	53 (+16)	+43.24%
brillig_slices	716 (+184)	+34.59%
closures_mut_ref	30 (+7)	+30.43%
missing_closure_env	25 (+3)	+13.64%
regression_6451	48 (+4)	+9.09%
references	315 (+25)	+8.62%
1_mul	67 (+5)	+8.06%
nested_array_in_slice	1,289 (+87)	+7.24%
derive	145 (+9)	+6.62%
3_add	50 (+3)	+6.38%
signed_arithmetic	271 (+16)	+6.27%
fold_2_to_17	621 (+36)	+6.15%
bench_2_to_17	354 (+18)	+5.36%
poseidon2	361 (+18)	+5.25%
integer_array_indexing	62 (+3)	+5.08%
fold_numeric_generic_poseidon	806 (+36)	+4.68%
no_predicates_numeric_generic_poseidon	806 (+36)	+4.68%
hashmap	27,602 (+946)	+3.55%
brillig_rc_regression_6123	181 (+6)	+3.43%
brillig_cow	393 (+12)	+3.15%
regression	749 (+20)	+2.74%
slices	2,323 (+60)	+2.65%
fold_complex_outputs	588 (+15)	+2.62%
uhashmap	16,724 (+414)	+2.54%
slice_dynamic_index	2,800 (+64)	+2.34%
eddsa	11,135 (+241)	+2.21%
regression_capacity_tracker	235 (+4)	+1.73%
regression_struct_array_conditional	558 (+4)	+0.72%
higher_order_functions	741 (+5)	+0.68%
array_sort	304 (+2)	+0.66%
sha2_byte	3,410 (+22)	+0.65%
7_function	643 (+4)	+0.63%
regression_5252	4,901 (+22)	+0.45%
conditional_1	1,342 (+5)	+0.37%
array_dynamic	321 (+1)	+0.31%
brillig_cow_regression	2,416 (+6)	+0.25%
6_array	433 (+1)	+0.23%
keccak256	1,782 (+4)	+0.22%
brillig_keccak	1,782 (+4)	+0.22%
array_dynamic_blackbox_input	1,178 (+2)	+0.17%
6	1,369 (+2)	+0.15%
sha256	2,056 (+3)	+0.15%
sha256_var_witness_const_regression	1,405 (+2)	+0.14%
conditional_regression_short_circuit	1,439 (+2)	+0.14%
brillig_sha256	797 (+1)	+0.13%
regression_4449	860 (+1)	+0.12%
sha256_var_padding_regression	5,254 (+6)	+0.11%
array_dynamic_nested_blackbox_input	995 (+1)	+0.10%
ram_blowup_regression	1,010 (+1)	+0.10%
ecdsa_secp256k1	1,014 (+1)	+0.10%
sha256_var_size_regression	2,048 (+2)	+0.10%
array_to_slice	1,044 (+1)	+0.10%
poseidonsponge_x5_254	4,506 (+4)	+0.09%
sha256_regression	7,278 (+6)	+0.08%
poseidon_bn254_hash_width_3	5,696 (+4)	+0.07%
poseidon_bn254_hash	5,696 (+4)	+0.07%
u128	2,912 (+1)	+0.03%

[github-actions]

Changes to circuit sizes

Generated at commit: e4e3815ce910ab2dd7f38541349a5edf9190b565, compared to commit: 852c87ae9ecdd441ee4c2ab3e78e86b2da07d8a4

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
regression_5252	+97,584 ❌	+282.07%	+130,183 ❌	+271.42%
conditional_1	+1,992 ❌	+47.93%	+4,823 ❌	+40.44%
references	+4 ❌	+66.67%	+5 ❌	+23.81%
hashmap	-22,567 ✅	-35.18%	-31,202 ✅	-22.62%
debug_logs	-6 ✅	-13.04%	-54 ✅	-73.97%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
regression_5252	132,180 (+97,584)	+282.07%	178,146 (+130,183)	+271.42%
conditional_1	6,148 (+1,992)	+47.93%	16,749 (+4,823)	+40.44%
references	10 (+4)	+66.67%	26 (+5)	+23.81%
poseidonsponge_x5_254	1,334 (+294)	+28.27%	1,431 (+176)	+14.02%
slice_dynamic_index	1,257 (+270)	+27.36%	6,907 (+449)	+6.95%
array_sort	55 (+2)	+3.77%	132 (+4)	+3.13%
sha256_regression	20,426 (-14,667)	-41.79%	200,575 (+3,112)	+1.58%
sha256_var_size_regression	11,973 (-4,188)	-25.91%	71,942 (+981)	+1.38%
array_dynamic	106 (+4)	+3.92%	3,728 (+14)	+0.38%
regression_capacity_tracker	117 (+4)	+3.54%	3,972 (+8)	+0.20%
side_effects_constrain_array	13 (+4)	+44.44%	2,773 (+5)	+0.18%
binary_operator_overloading	284 (+2)	+0.71%	4,465 (+2)	+0.04%
bench_eddsa_poseidon	16,441 (+2)	+0.01%	19,588 (+2)	+0.01%
eddsa	64,631 (+2)	+0.00%	65,817 (+2)	+0.00%
conditional_regression_short_circuit	370 (-4)	-1.07%	11,154 (-5)	-0.04%
conditional_2	19 (-2)	-9.52%	2,778 (-3)	-0.11%
schnorr	1,513 (-6)	-0.39%	23,906 (-26)	-0.11%
regression_3607	37 (-2)	-5.13%	2,798 (-4)	-0.14%
conditional_regression_661	24 (-6)	-20.00%	2,792 (-5)	-0.18%
array_if_cond_simple	102 (-6)	-5.56%	3,125 (-7)	-0.22%
regression_mem_op_predicate	47 (-9)	-16.07%	3,576 (-10)	-0.28%
slices	787 (-54)	-6.42%	3,932 (-21)	-0.53%
u128	655 (-26)	-3.82%	4,665 (-25)	-0.53%
nested_array_in_slice	941 (+48)	+5.38%	5,473 (-40)	-0.73%
regression	117 (-25)	-17.61%	3,655 (-29)	-0.79%
bigint	1,085 (-81)	-6.95%	8,043 (-74)	-0.91%
sha256	1,573 (-309)	-16.42%	20,921 (-390)	-1.83%
hash_to_field	507 (-75)	-12.89%	3,549 (-69)	-1.91%
nested_array_dynamic	3,281 (+115)	+3.63%	12,650 (-280)	-2.17%
sha256_var_witness_const_regression	1,368 (-309)	-18.43%	16,828 (-390)	-2.27%
ram_blowup_regression	154,324 (-19,200)	-11.06%	659,201 (-17,664)	-2.61%
hashmap	41,588 (-22,567)	-35.18%	106,757 (-31,202)	-22.62%
debug_logs	40 (-6)	-13.04%	19 (-54)	-73.97%

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: e4e3815ce910ab2dd7f38541349a5edf9190b565, compared to commit: 852c87ae9ecdd441ee4c2ab3e78e86b2da07d8a4

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
tuples	+16 ❌	+59.26%
closures_mut_ref	+7 ❌	+36.84%
brillig_slices	+197 ❌	+27.71%
missing_closure_env	+3 ❌	+16.67%
regression_6451	+4 ❌	+11.11%
1_mul	+5 ❌	+10.00%
references	+36 ❌	+8.76%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
tuples	43 (+16)	+59.26%
closures_mut_ref	26 (+7)	+36.84%
brillig_slices	908 (+197)	+27.71%
missing_closure_env	21 (+3)	+16.67%
regression_6451	40 (+4)	+11.11%
1_mul	55 (+5)	+10.00%
references	447 (+36)	+8.76%
3_add	40 (+3)	+8.11%
signed_arithmetic	219 (+16)	+7.88%
regression	2,912 (+209)	+7.73%
slices	4,114 (+284)	+7.42%
slice_dynamic_index	4,662 (+307)	+7.05%
derive	142 (+9)	+6.77%
nested_array_in_slice	1,556 (+87)	+5.92%
integer_array_indexing	76 (+3)	+4.11%
poseidon2	730 (+26)	+3.69%
fold_numeric_generic_poseidon	5,414 (+175)	+3.34%
no_predicates_numeric_generic_poseidon	5,414 (+175)	+3.34%
brillig_rc_regression_6123	297 (+8)	+2.77%
poseidon_bn254_hash	173,413 (+3,861)	+2.28%
poseidon_bn254_hash_width_3	173,413 (+3,861)	+2.28%
regression_5252	971,236 (+20,030)	+2.11%
poseidonsponge_x5_254	194,877 (+3,960)	+2.07%
fold_complex_outputs	904 (+15)	+1.69%
hashmap	59,252 (+831)	+1.42%
7_function	2,847 (+35)	+1.24%
sha2_byte	52,792 (+561)	+1.07%
brillig_cow	1,145 (+12)	+1.06%
eddsa	743,466 (+6,187)	+0.84%
regression_struct_array_conditional	1,576 (+12)	+0.77%
array_sort	542 (+4)	+0.74%
uhashmap	154,751 (+1,133)	+0.74%
regression_capacity_tracker	910 (+4)	+0.44%
array_dynamic_blackbox_input	20,021 (+66)	+0.33%
higher_order_functions	1,520 (+5)	+0.33%
array_dynamic	499 (+1)	+0.20%
conditional_1	5,865 (+5)	+0.09%
6_array	1,840 (+1)	+0.05%
array_to_slice	2,476 (+1)	+0.04%
fold_2_to_17	131,513,323 (+52,820)	+0.04%
regression_4449	219,832 (+70)	+0.03%
u128	25,436 (+8)	+0.03%
sha256_var_witness_const_regression	7,038 (+2)	+0.03%
sha256	10,847 (+3)	+0.03%
6	7,359 (+2)	+0.03%
conditional_regression_short_circuit	7,434 (+2)	+0.03%
brillig_sha256	4,201 (+1)	+0.02%
array_dynamic_nested_blackbox_input	4,630 (+1)	+0.02%
bench_2_to_17	144,713,530 (+27,770)	+0.02%
ecdsa_secp256k1	7,076 (+1)	+0.01%
sha256_var_size_regression	18,333 (+2)	+0.01%
brillig_keccak	37,103 (+4)	+0.01%
keccak256	37,103 (+4)	+0.01%
brillig_cow_regression	583,891 (+52)	+0.01%
sha256_regression	126,260 (+6)	+0.00%
sha256_var_padding_regression	234,843 (+6)	+0.00%
ram_blowup_regression	877,405 (+1)	+0.00%

[jfecher]

The brillig size increases are likely from the temporary store changes while mem2reg is fixed (should it be in this PR or separate?)
while the acir changes are likely due to the increased amount of value mergers which could possibly be helped by #6073.

[jfecher]

Some large bytecode regressions here unfortunately. This is a correctness issue though and the bytecode size fixes in #6460 and #6490 are looking less certain so I think we should merge this now. We can continue working on these fixes or other ones in the future.