Conversation
There was a problem hiding this comment.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.
| Benchmark suite | Current: 2c4ed3d | Previous: ae008d3 | Ratio |
|---|---|---|---|
test_report_noir-lang_noir_bigcurve_ |
278 s |
220 s |
1.26 |
This comment was automatically generated by workflow using github-action-benchmark.
CC: @TomAFrench
| // If `lhs` and `rhs` are known constants then we can calculate the result at compile time. | ||
| // `rhs` must be non-zero. | ||
| (Some(lhs_const), Some(rhs_const), _) if !rhs_const.is_zero() => { | ||
| (Some(lhs_const), Some(rhs_const), _) if rhs_const.to_u128() != 0 => { |
There was a problem hiding this comment.
I checked this and the case where there's a difference is for this field element: 340282366920938463463374607431768211456.
That's not zero, but to_u128 will return zero as it overflows the maximum u128.
Just noting this here, the fix is probably good.
|
🥷 #8180 |
|
I thought about fixing it this way, but decided that we can figure it out at compile time, we have the information (the constants) we just shouldn’t divide. |
|
Superseded by #8180 |
Description
Problem*
Resolves #8175
Summary*
The zero check is not working for some reason when doing constant folding division in acir-gen, instead I check the number that is used for the constant folding.
Additional Context
Documentation*
Check one:
PR Checklist*
cargo fmton default settings.