mshinwell
commented
8 years ago We should think about this in the context of re-working specialised argument annotations as Leo has described. That rework is needed so unbox-closures can work properly; at the moment (e.g. in examples coming from Core_sequence) chains of functions cannot be lifted because the topmost one has a specialised argument, which in fact won't ever be specialised in the example, but the compiler thinks it might be one day.
A problem that we encountered starts with a multiply recursive set of closures (f and g)
f is the entry-point which calls g g has a free variables v
g is unboxed for v. It is renamed to g', with one new argument v and a new stub g is introduced.
v happens to be lifted to toplevel later and uses in g (the stub) are replaced by read_symbol_field v.(0)
A bug prevents v to be substituted in g' (a non handled case in simplify_move_within_set_of_closure)
g' now has a specialised argument (v) refering to an outside variable (the same the free variable was refering to). But it is not a free variable of the function anymore since g doesn't need it and it gets removed.
The problem being that the specialised argument refer to an outside variable by relying on free variables to keep the reference. But it could happen that this reference got away, but the argument is not substituted.
This case should be a optimisation bug, but not a correctness one.
We could prevent removing free variables when there is a specialised argument refering to it, but that would defeat the purpose of unbox closures.