above the goto, there's an iconst so at stop_3 the ifeq will trigger. We can remove that
above stop_3 there's a iconst to allow you to pass the stop if you weren't sent there by somewhere else. We can remove that. since we're going to remove the label
remove stop_3 and the ifeq below it. Notice the ifeq jumps to stop_1
change any incoming jumps to now jump to stop_1 (in this case only our goto_3)
replacing all such patterns in the above code results in
the following in this order: iconst_0, goto labelA
somewhere else the following in this order: iconst_1, labelA, ifeq labelB
all jumps going to labelA are of the form: iconst_0, goto labelA
Postconditions:
all jumps to labelA now go to labelB and the iconst_0 above is removed
at iconst_1, labelA and ifeq labelB are all removed
Why this is ok (cause this is a hard once to convince). Because with iconst_1 directly above labelA any jump or code flow will pass over it EXCEPT the jumps directly going to labelA (condition 1). All such jumps going to labelA will pass through to labelB (condition 2). So we know this will have no adverse affects.
gjh33
commented
7 years ago
if jumping to a another stop we can remove this. Let me show you an example, the semantics are hard to phrase. This is from bench01/backtracksolver.j
Note the first goto stop_3. What we can change:
replacing all such patterns in the above code results in
Removed 8 lines
Conditions:
Postconditions:
Why this is ok (cause this is a hard once to convince). Because with iconst_1 directly above labelA any jump or code flow will pass over it EXCEPT the jumps directly going to labelA (condition 1). All such jumps going to labelA will pass through to labelB (condition 2). So we know this will have no adverse affects.