feat: remove truncations which can be seen to be noops using type information

[TomAFrench]

…

Description

Problem*

Resolves

Summary*

Truncates which occur on outputs of Binary(BinaryOp::Div) can sometimes be determined to be noops based on type information.

Put simply, if we have (numerator / constant_denom) as T then if type_of(numerator)::max / constant_denom fits inside T then we don't need to truncate the value.

Additional Context

Testing this on noir-rsa takes us from

+---------+----------------------+--------------+----------------------+
| Package | Expression Width     | ACIR Opcodes | Backend Circuit Size |
+---------+----------------------+--------------+----------------------+
| dkim    | Bounded { width: 3 } | 1649234      | 3049613              |
+---------+----------------------+--------------+----------------------+

to

+---------+----------------------+--------------+----------------------+
| Package | Expression Width     | ACIR Opcodes | Backend Circuit Size |
+---------+----------------------+--------------+----------------------+
| dkim    | Bounded { width: 3 } | 1486175      | 2764246              |
+---------+----------------------+--------------+----------------------+

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [Exceptional Case] 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: af98346f989131f3817ff6892164c1134a3c3606, compared to commit: 5be049eee6c342649462282ee04f6411e6ea392c

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
regression	-20 ✅	-8.13%	0 ➖	0.00%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
regression	226 (-20)	-8.13%	4,130 (0)	0.00%

[jfecher]

Looks good. Should we have a test for this optimization though? I noticed none of our tests were affected by this at all.

[TomAFrench]

Yep, I should add some tests for this as there's scope for off-by-one errors. Will do that before we merge this.

[TomAFrench]

I've added a test showing the two relevant edgecases. There's a good deal of code duplication between them but there doesn't seem to be a nice way to encapsulate the building of the SSA while still having the access to variables needed for the test.

We could in future move these tests to sit in function_builder as what we're really testing is the simplifications made as an instruction is inserted rather than anything innately related to the constant folding pass. We can then rewrite the test to not use constant folding at all which will allow more code reuse.

[jfecher]

Thanks!