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: 5573 Reporter: pascal_cuoq Assigned to:@alainfrisch Status: closed (set by @xavierleroy on 2015-12-11T18:25:51Z) Resolution: fixed Priority: low Severity: tweak Version: 3.12.1 Target version: 4.01.1+dev Fixed in version: 4.02.0+dev Category: back end (clambda to assembly) Duplicate of:#5537 Related to:#4074#5546 Monitored by:@gasche@yakobowski
Bug description
Consider the following example, in which module T.M.N.O.P contains a function v_f and a non-functional value v.
$ cat t.ml
module M =
struct
module N =
struct
module O =
struct
module P =
struct
let v = Some 5;;
let v_f() = Some 5;;
end
end
end
end
$ cat u.ml
let _ =
match T.M.N.O.P.v, (T.M.N.O.P.v_f()) with
Some a, Some b -> exit (a+b)
| _ -> exit 0
I understand that there are reasons for values to be compiled and inlined differently from code, because values live in the heap and are registered as roots for the GC and you don't want to register roots that lie in the code segment for the GC to update when the value is moved. But it is surprising that the function call T.M.N.O.P.v_f() in u.ml is compiled more efficiently than the access to the statically determined value T.M.N.O.P.v.
Would it not be possible to fix the memory location of T.M.N.O.P.v, or at least of T.M.N.O.P, so that the access to the value can be compiled with 2 (respectively 1) memory access? Or to upgrade the link interfaces between modules so that the code generated for T.M.N.O.P.v in u.ml is the same as the implementation of function v_f in t.ml?
A workaround is to move to separate files modules that are currently gratuitously nested, but that sounds like the kind of busywork one had to do in the 1990s when authoring C libraries, putting each function in its own file to circumvent linker limitations of some platforms, if Xavier remembers teaching me this trick.
The text was updated successfully, but these errors were encountered:
Original bug ID: 5573
Reporter: pascal_cuoq
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:25:51Z)
Resolution: fixed
Priority: low
Severity: tweak
Version: 3.12.1
Target version: 4.01.1+dev
Fixed in version: 4.02.0+dev
Category: back end (clambda to assembly)
Duplicate of: #5537
Related to: #4074 #5546
Monitored by: @gasche @yakobowski
Bug description
Consider the following example, in which module T.M.N.O.P contains a function v_f and a non-functional value v.
$ cat t.ml
module M =
struct
module N =
struct
module O =
struct
module P =
struct
let v = Some 5;;
let v_f() = Some 5;;
end
end
end
end
$ cat u.ml
let _ =
match T.M.N.O.P.v, (T.M.N.O.P.v_f()) with
Some a, Some b -> exit (a+b)
| _ -> exit 0
I understand that there are reasons for values to be compiled and inlined differently from code, because values live in the heap and are registered as roots for the GC and you don't want to register roots that lie in the code segment for the GC to update when the value is moved. But it is surprising that the function call T.M.N.O.P.v_f() in u.ml is compiled more efficiently than the access to the statically determined value T.M.N.O.P.v.
$ ocamlopt -S t.ml u.ml
...
movq (%rax), %rax
movq (%rax), %rax
movq (%rax), %rax
movq (%rax), %rax
movq (%rax), %rax
...
movq %rax, 0(%rsp)
movq $1, %rax
call _camlT__v_f_1031
...
Would it not be possible to fix the memory location of T.M.N.O.P.v, or at least of T.M.N.O.P, so that the access to the value can be compiled with 2 (respectively 1) memory access? Or to upgrade the link interfaces between modules so that the code generated for T.M.N.O.P.v in u.ml is the same as the implementation of function v_f in t.ml?
A workaround is to move to separate files modules that are currently gratuitously nested, but that sounds like the kind of busywork one had to do in the 1990s when authoring C libraries, putting each function in its own file to circumvent linker limitations of some platforms, if Xavier remembers teaching me this trick.
The text was updated successfully, but these errors were encountered: