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
Original bug ID: 7022 Reporter:@alainfrisch Assigned to:@alainfrisch Status: closed (set by @xavierleroy on 2017-02-16T14:14:35Z) Resolution: fixed Priority: normal Severity: minor Fixed in version: 4.03.0+dev / +beta1 Category: back end (clambda to assembly) Monitored by:@diml@hcarty
Bug description
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:
It's easy to see that this can yield quadratic compile time for expressions such as:
let x = x +. 1. in
let x = x +. 1. in
...
let x = x +. 1. in
This misses some simple unboxing opportunities. Consider:
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:
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.
The text was updated successfully, but these errors were encountered:
Original bug ID: 7022
Reporter: @alainfrisch
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2017-02-16T14:14:35Z)
Resolution: fixed
Priority: normal
Severity: minor
Fixed in version: 4.03.0+dev / +beta1
Category: back end (clambda to assembly)
Monitored by: @diml @hcarty
Bug description
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:
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:
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.
The text was updated successfully, but these errors were encountered: