reactorlabs / sourir

6 stars 5 forks source link

Order of optimizations #99

Open mhyee opened 7 years ago

mhyee commented 7 years ago

This is mainly for discussion, maybe there isn't anything to do (right now).

Consider this example program:

mut w = 0
const z = w
w <- 1
print w
print z

If we run all optimization passes, the default order is to run make_const before hoist_assign. Here's what we get if we run with --opt=make_const,hoist_assign (I'm intentionally omitting some optimizations to keep the example simpler):

mut w_1 = 1
mut w = 0
const z = w
print w_1
print z

We removed the assignment, at the cost of adding another mut variable.

A better ordering is --opt=hoist_assign,make_const:

const w_1 = 1
const w = 0
const z = w
print w_1
print z

Now we eliminated the assignment and the mutable variable.


Was there a reason to put make_const before hoist_assign? Is there an optimal ordering of optimizations, or do we have to start thinking about fixpoints? (I guess this wouldn't be too difficult with the API we currently have.)

o- commented 7 years ago

My idea with the current api was to run the optimizations in a loop until either fixpoint or upper limit on the number of iterations.

At least from my side there was no conscious decision about the ordering and as far as I know its an open question how different optimizations interact and what a good order is.