Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Unboxing should be done earlier, avoiding a second pass #7022
Original bug ID: 7022
The unboxing strategy (for floats and boxed integers) in Cmmgen is now as follow:
When translating an expression "let x = e1 in e2", one translate first e2 (assuming x is a general value), then one decides if e1 will produce a boxed value, and if so, one rewrites the translated e2 to replace references on the boxed x to references to the unboxed x.
This is not very good, both for compile-time complexity and for the strength of unboxing:
let x = x +. 1. in let x = x +. 1. in ... let x = x +. 1. in
let f b x0 = let x = x0 +. 1. in let y = if b then x else x +. 1. in y *. 2.
When "let y = ... in ..." is translated, one doesn't know yet that x will be unboxed. So the bound expression (if b then ...) cannot be certain to produce a boxed value (then branch returns x), and so y won't be unboxed:
(function camlFoo__f_1203 (b/1204: val x0/1205: val) (let (x/1210 (+f (load float64u x0/1205) 1.) y/1207 (if (!= b/1204 1) (alloc 2301 x/1210) (alloc 2301 (+f x/1210 1.)))) (alloc 2301 (*f (load float64u y/1207) 2.))))
These two issues can be addressed by compiling the body e2 of "let x = e1 in e2" under the knowledge that x is unboxed (since this can now be decided looking only at e1). This would also be more direct than the current "reverse engineering" of the unboxing construction in Cmmgen.subst_boxed_number.
Comment author: @alainfrisch
I'm working on this new strategy here: