-
Notifications
You must be signed in to change notification settings - Fork 329
chore(licm): Identify untested code; refactoring; minor fixes #9718
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚠️ 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: 60d09ad | Previous: 8d5ae13 | Ratio |
---|---|---|---|
test_report_zkpassport_noir-ecdsa_ |
2 s |
1 s |
2 |
This comment was automatically generated by workflow using github-action-benchmark.
CC: @TomAFrench
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⚠️ Performance Alert ⚠️
Possible performance regression was detected for benchmark 'Execution Time'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20
.
Benchmark suite | Current: 2be3e26 | Previous: 8d5ae13 | Ratio |
---|---|---|---|
private-kernel-inner |
0.019 s |
0.014 s |
1.36 |
This comment was automatically generated by workflow using github-action-benchmark.
CC: @TomAFrench
…alse and then true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Description
Problem*
Trying to find pieces of logic not covered by unit or integration tests.
Summary*
Add more unit test coverage to LICM.
Refactor and fix some stuff:
Constrain
andRangeCheck
fromcan_be_hoisted_from_loop_bounds
: they don't look at the bounds, and the conditions they check are redundant withcan_be_hoisted
.Call
fromcan_be_hoisted_from_loop_bounds
: same reason as above.BlockContext::can_be_hoisted_with_control_dependence
: I thought the extra jumping around to callcan_be_hoisted
again withtrue
was confusing, and it was clearer to see the calls tocan_be_hoisted
withfalse
andtrue
next to each other, with the latter being restricted byblock_context.can_hoist_control_dependent_instruction()
.can_be_hoisted
to returnYes | No | WithPredicate
, rather than having to call it twice withfalse
andtrue
; this way if it returnsNo
we don't have to retry in futility, and I think it reads clearer.false
for loops without an exit block from the header inis_fully_executed
. It used returntrue
, but two examples I found were 1) an actual infiniteloop
inregression_7103
and 2) awhile true
loop with abreak
created by the fuzzer to avoid infinite loops. The latter is clearly not in the spirit of the method, as it has abreak
.get_const_upper_bound
, e.g.while <bool-variable>
.is_impure
.ConstrainNotEqual
Untested code
The following changes don't cause any test failure:
can_be_hoisted_from_loop_bounds
:ArrayGet
can be disabledArrayGet
canreturn true
instead offalse
Constrain(..) | ConstrainNotEqual(..) | RangeCheck { .. }
can be disabledCall { func, .. }
can be disabledcan_be_hoisted
:Call
/Purity::Pure
: returnfalse
instead oftrue
Call
/Purity::PureWithPredicate
: returnfalse
instead ofhoist_with_predicate
Call
/ purityNone
: returntrue
instead offalse
MakeArray
: returntrue
orfalse
instead offunction.runtime().is_acir()
can_evaluate_binary_op
:Add | Mul | Sub
whenunchecked: true
: returnfalse
instead oftrue
Div | Mod
: returnfalse
instead oftrue
when!value.is_zero()
simplify_from_loop_bounds
:SimplifyResult::Remove
: returnfalse
instead oftrue
simplify_induction_variable
:Constrain
: removeloop_context.no_break
from conditionConstrainNotEqual
:loop_context.no_break
from conditionblock_context.can_simplify_control_dependent_instruction()
from conditionsimplify_induction_variable_in_binary
:false if upper_bound <= constant.inc()
if we remove.inc()
false if lower_bound > constant
if we returnfalse_value
instead oftrue_value
true if lower_bound >= constant
if we returntrue_value
instead offalse_value
false if upper_bound <= constant.inc()
if we returntrue_value
instead offalse_value
This is not an exhaustive list, just what I found by tinkering with conditions.
I'll open follow up PRs to add tests, but wanted to get this PR reviewed because of the refactoring it contains.
Additional Context
I used the following commands to look for failing tests:
Documentation*
Check one:
PR Checklist*
cargo fmt
on default settings.