You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The optimization in 5.12.1. that gets rid of unused blocks via laziness is very hard to trigger: it requires a combination of a nested conditional and a constant boolean expression, e.g. as produced by shrinking
if (False and x > 4):
print(1)
else:
print(2)
Nearly all the benefit of the version of create_block on p. 87, including the block count reduction shown in Fig. 5.16, is due the first case that short-cuts Gotos. But this could have been done without involving laziness. Also, this case isn't discussed in the text at all.
The exercise in 5.12.2 becomes much more interesting if blocks can flow into one another, so that final Gotos can be removed altogether after suitable reordering. This is easy to support by allowing an alternative representation of x86 code as a list of blocks rather than an (unordered) dictionary. (Or the list representation can just replace the dictionary.) Doing a good job of reordering is non-trivial, but decent heuristics are not hard to find. And this also provides a great opportunity to remove unreachable blocks (without the complications of the lazy approach in 5.12.1.)
The text was updated successfully, but these errors were encountered:
I've pulled the short-cutting of Goto into the first version of create_block and then introduced an example along the lines of what you give above to motivate the lazy evaluation.
Those are neat thoughts regarding reordering blocks.
Maybe too late for this edition, but...
Section 5.12 is still not very convincing.
create_block
on p. 87, including the block count reduction shown in Fig. 5.16, is due the first case that short-cutsGoto
s. But this could have been done without involving laziness. Also, this case isn't discussed in the text at all.Goto
s can be removed altogether after suitable reordering. This is easy to support by allowing an alternative representation of x86 code as a list of blocks rather than an (unordered) dictionary. (Or the list representation can just replace the dictionary.) Doing a good job of reordering is non-trivial, but decent heuristics are not hard to find. And this also provides a great opportunity to remove unreachable blocks (without the complications of the lazy approach in 5.12.1.)The text was updated successfully, but these errors were encountered: