feat: unconstrained optimizations for BoundedVec

[asterite]

Description

Problem

Resolves #7094

Summary

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]

Compilation Report

Program	Compilation Time	%
sha256_regression	1.030s	0%
regression_4709	0.825s	2%
ram_blowup_regression	16.300s	1%
rollup-root	3.532s	-1%
rollup-merge	2.034s	-3%
rollup-block-root-single-tx	145.000s	0%
rollup-block-root-empty	2.200s	5%
rollup-block-root	141.000s	1%
rollup-block-merge	3.678s	4%
rollup-base-public	28.040s	1%
rollup-base-private	10.020s	-2%
private-kernel-tail	1.007s	0%
private-kernel-reset	6.204s	2%
private-kernel-inner	1.934s	-7%

[github-actions]

Execution Report

Program	Execution Time	%
sha256_regression	0.054s	1%
regression_4709	0.001s	0%
ram_blowup_regression	0.596s	0%
rollup-root	0.104s	0%
rollup-merge	0.007s	0%
rollup-block-root	38.000s	-1%
rollup-block-merge	0.104s	0%
rollup-base-public	1.222s	0%
rollup-base-private	0.451s	-1%
private-kernel-tail	0.019s	0%
private-kernel-reset	0.315s	1%
private-kernel-inner	0.068s	0%

[github-actions]

Execution Memory Report

Program	Peak Memory
keccak256	74.690
workspace	123.290
regression_4709	315.980
ram_blowup_regression	512.600
rollup-root	498.780
rollup-merge	473.410
rollup-block-root	1230.000
rollup-block-merge	498.790
rollup-base-public	734.430
rollup-base-private	590.870
private-kernel-tail	180.880
private-kernel-reset	245.490
private-kernel-inner	208.890

[github-actions]

Compilation Memory Report

Program	Peak Memory
keccak256	77.600
workspace	123.910
regression_4709	424.110
ram_blowup_regression	1460.000
rollup-root	601.640
rollup-merge	494.480
rollup-block-root-single-tx	16060.000
rollup-block-root-empty	489.110
rollup-block-root	16070.000
rollup-block-merge	601.630
rollup-base-public	2380.000
rollup-base-private	1140.000
private-kernel-tail	207.300
private-kernel-reset	584.440
private-kernel-inner	294.660

[asterite]

I was wondering if we could have something like this in the standard library:

use std::runtime::is_unconstrained;

fn main() {
    for_loop::<5>(0, 3, |i| { println(f"{i}"); })
}

fn for_loop<let Max: u32>(start: u32, end: u32, f: fn(u32) -> ()) {
    if is_unconstrained() {
        if end < Max {
            for i in start..end {
                f(i);
            }
        }
    } else {
        for i in start..Max {
            if i < end {
                f(i);
            }
        }
    }
}

Using --show-ssa it seems the compiler optimizes this well, but I don't know if it would make compilation slower, or if it would make the code less clear (it could at least be a pub(crate) function)

[aakoshh]

I was wondering if we could have something like this in the standard library:

Wouldn't it make sense to have an assert(end <= Max) instead of if end < Max {?

Does it work with lambdas that capture mutable variables?

[aakoshh]

@TomAFrench so is there a way now to see the output of https://github.com/noir-lang/noir/actions/runs/12869320334/job/35878119440?pr=7119 ?

[TomAFrench]

Circuit sizes are still posted as comments as they're not prone to fluctuations and so are only posted when there's a change.

[aakoshh]

Looks correct. Would be nice to see the impact.

[aakoshh]

Ah ok, because I can't see them at https://noir-lang.github.io/noir/dev/bench/
So basically we don't see anything because it didn't affect the circuits we have in the integration tests (or at least not negatively?).

[TomAFrench]

Yes that's correct. If these metrics are unchanged then no comment is posted, this is completely unchanged by #7111 as that only affected time and memory benchmarks.

[TomAFrench]

I was wondering if we could have something like this in the standard library

Yeah that looks sensible and would be efficient to compile (is_unconstrained is resolved at ssa_gen time so the unused branch is never even generated). I don't think it's something that we want to expose from the stdlib but if it's something we'd find ourselves doing over and over then let's use it internally.