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: 6866 Reporter:@alainfrisch Assigned to:@alainfrisch Status: closed (set by @xavierleroy on 2017-02-16T14:15:02Z) Resolution: fixed Priority: normal Severity: minor Target version: 4.03.0+dev / +beta1 Fixed in version: 4.03.0+dev / +beta1 Category: back end (clambda to assembly) Tags: patch Monitored by:@gasche@diml@jmeber@hcarty
Bug description
The following code shows a case where float boxing is not eliminated:
type t = {mutable x: float}
let f r = r.x <- (let x = r.x in x)
A patch is attached: the body of a let used in an unboxing context is itself compiled knowing it will be unboxed (before deciding whether to unbox the bound identifier).
However, the patch doesn't address:
let f r = r.x <- (if r.x > 0. then let x = r.x in x else 0.)
A better solution would probably to always pass to Cmm.transl some information about the unboxing context, instead of unboxing "after the fact".
let f x =
let v = ref 0. in
v := (let y = 1. +. x in y)
The issue here is that the statement "v := ..." is first compiled without knowing that v will be unboxed. During this pass, nothing tells us that the "let y = .. in ..." will have its result unboxed. So boxing of "y" is not eliminated. It's only once "v := ..." is compiled to cmm that the compiler decides that "v" can be unboxed, but it's too late.
This results in (again in -g mode for such a simple example):
One approach could be to keep in a table the fact that y/1331 is the unboxed version of y/1327 so that once "load y" is to be built (to unbox v), it is immediately simplified to y/1331 (and then eliminate the dead binding for y/1327).
Original bug ID: 6866
Reporter: @alainfrisch
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2017-02-16T14:15:02Z)
Resolution: fixed
Priority: normal
Severity: minor
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.03.0+dev / +beta1
Category: back end (clambda to assembly)
Tags: patch
Monitored by: @gasche @diml @jmeber @hcarty
Bug description
The following code shows a case where float boxing is not eliminated:
It produces this cmm code:
The reason is that the "let x =" is processed without the knowledge that its result will be used in a context which unboxes the float.
This kind of cases can easily occur because of inlining. It shouldn't be too hard to handle then in cmmgen.
(Note: the very simple example give above is simplified if we don't compile with -g.)
File attachments
The text was updated successfully, but these errors were encountered: