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: 6029 Reporter:@ppedrot Status: confirmed (set by @damiendoligez on 2013-06-18T13:50:17Z) Resolution: open Priority: normal Severity: feature Version: 3.12.1 Category: middle end (typedtree to clambda) Monitored by:@gasche meurer @mauny@alainfrisch
Bug description
Currently, only Lazy.force is compiled as a primitive function, while the keyword "lazy" is not. This has various drawbacks:
One has to explicitly put Lazy.from_val to get an efficient lifting, while the compiler could do it automatically in front of syntactical values;
Even doing so, there is a small penalty to pay because of the special treatment of float values, which could be inferred statically, similarly to array accesses.
This is unlikely to happen, but that also permits code rewriting such as "Lazy.force (lazy t)" as "t".
Steps to reproduce
The following examples generates a lot of assembly noise:
type 'a stream = 'a node Lazy.t
and 'a node = Cons of 'a * 'a stream
let cons1 x s = lazy (Cons (x, s))
let cons2 x s = Lazy.from_val (Cons (x, s))
while they could be compiled exactly like:
let cons3 x s = Obj.magic (Cons (x, s))
The text was updated successfully, but these errors were encountered:
One has to explicitly put Lazy.from_val to get an efficient lifting, while the compiler could do it automatically in front of syntactical values;
There is already some code in translcore.ml to do so (see the case for Texp_lazy).
The case of pure constructors with arguments (and records) is currently not optimized. I'm not sure why, but this is easy to change without changing more deeply the way "lazy" is compiled.
Even doing so, there is a small penalty to pay because of the special treatment of float values, which could be inferred statically, similarly to array accesses.
Note to anyone who wants to implement this: float values cannot always be inferred statically, so be ready to have the run-time test in some cases.
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.
Original bug ID: 6029
Reporter: @ppedrot
Status: confirmed (set by @damiendoligez on 2013-06-18T13:50:17Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.12.1
Category: middle end (typedtree to clambda)
Monitored by: @gasche meurer @mauny @alainfrisch
Bug description
Currently, only Lazy.force is compiled as a primitive function, while the keyword "lazy" is not. This has various drawbacks:
One has to explicitly put Lazy.from_val to get an efficient lifting, while the compiler could do it automatically in front of syntactical values;
Even doing so, there is a small penalty to pay because of the special treatment of float values, which could be inferred statically, similarly to array accesses.
This is unlikely to happen, but that also permits code rewriting such as "Lazy.force (lazy t)" as "t".
Steps to reproduce
The following examples generates a lot of assembly noise:
type 'a stream = 'a node Lazy.t
and 'a node = Cons of 'a * 'a stream
let cons1 x s = lazy (Cons (x, s))
let cons2 x s = Lazy.from_val (Cons (x, s))
while they could be compiled exactly like:
let cons3 x s = Obj.magic (Cons (x, s))
The text was updated successfully, but these errors were encountered: