chore: optimise older opcodes in reverse order

[guipublic]

Description

Problem*

Related to #6451 and #6461

Summary*

Handle the case where we can optimise an older opcode

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

[github-actions]

Changes to circuit sizes

Generated at commit: eb6d26bf5fa04cb1d4f5945c51486adc2fbdb50d, compared to commit: 5ccde8196400a9b99e5c3c4d9af0e3136e72b4cb

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
regression_6451	-1 ✅	-6.25%	-1 ✅	-3.57%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
regression_6451	15 (-1)	-6.25%	27 (-1)	-3.57%

[guipublic]

The increase in circuit size is not expected. This is worrying and we should not merge the PR which is supposed to improve (only a little bit but still) this number.

[github-actions]

Peak Memory Sample

Program	Peak Memory
keccak256	81.46M
workspace	122.24M
regression_4709	333.68M
ram_blowup_regression	2.55G

[TomAFrench]

Closes #6668?

[aakoshh]

This looks good as far as I understand it.

So to be clear, what's happening is that previously we went through opcodes 0, 1, 2, etc and only considered merging i into b if i < b, so earlier opcodes got merged into later opcodes. We did this when we found a witness w that was only used by i and b.

However, there could have been a witness w' that was used by i, j and k, and after merging i into b we may or may not have recognised that we can merge j into k now that w' was only used in two opcodes: if we visited j earlier than i then we wouldn't eliminate it.

But now we can, because when we hit k we see that j can be merged into it 🎉

Does this completely eliminate the need for doing multiple passes with the expression merger?

[aakoshh]

Does this completely eliminate the need for doing multiple passes with the expression merger?

I guess it doesn't, because if for example we have a witness that is only used by the last two gates, and we eliminate the one before last, it might unlock the merger of earlier gates that we won't be visiting again.

For example:

Gate	Witness A	Witness B	Witness C
0	x		x
1	x
2	x	x	x
3		x

When we reach gate 2, we recognise that B is only used by 2 and 3, so we merge 2 into 3.
This causes gate 3 to use A and C as well:

Gate	Witness A	Witness B	Witness C
0	x		x
1	x
3	x	x	x

When we move to gate 3, we recognise that C is only used by 0 and 3, so we merge 0 into 3, and get:

Gate	Witness A	Witness B	Witness C
1	x
3	x	x	x

Alas, we break out of the loop and never consider merging 1 into 3, even though A is only used by 2 gates now.

[guipublic]

Does this completely eliminate the need for doing multiple passes with the expression merger?

I guess it doesn't, because (...)

Yes I agree it does not eliminate all in one pass.

[aakoshh]

Nice!