Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005573OCamlback end (clambda to assembly)public2012-04-04 20:332015-12-11 19:25
Assigned Tofrisch 
PlatformOSOS Version
Product Version3.12.1 
Target Version4.01.1+devFixed in Version4.02.0+dev 
Summary0005573: Access to values in nested modules
DescriptionConsider the following example, in which module T.M.N.O.P contains a function v_f and a non-functional value v.

$ cat
module M =
  module N =
    module O =
      module P =
        let v = Some 5;;
        let v_f() = Some 5;;
$ cat
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 is compiled more efficiently than the access to the statically determined value T.M.N.O.P.v.

$ ocamlopt -S
    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 is the same as the implementation of function v_f in

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.
TagsNo tags attached.
Attached Files

- Relationships
duplicate of 0005537closedfrisch reducing repeated indirections to access variables in nested modules 
related to 0005546closedfrisch moving a function into an internal module slows down its use 
related to 0004074acknowledged Patch for in-place compilation of structures 

-  Notes
pascal_cuoq (reporter)
2012-04-04 22:28

This is actually more related (a duplicate, even) of 5537.
gasche (developer)
2012-04-04 22:45

5573 duplicating 5537, that seems fitting.

(I assumed mantis would extend the "related to" relation by transitivity and also display 5537 here, but well.)
doligez (administrator)
2013-08-19 14:42

Same questions as for 0005537: is this fixed by 0005546?

- Issue History
Date Modified Username Field Change
2012-04-04 20:33 pascal_cuoq New Issue
2012-04-04 22:17 gasche Relationship added related to 0005546
2012-04-04 22:28 pascal_cuoq Note Added: 0007281
2012-04-04 22:45 gasche Note Added: 0007282
2012-04-04 22:46 gasche Relationship added duplicate of 0005537
2012-04-04 22:46 gasche Status new => acknowledged
2012-04-04 22:47 gasche Relationship added related to 0004074
2012-09-06 16:43 doligez Target Version => 4.00.1+dev
2012-09-21 14:13 doligez Target Version 4.00.1+dev => 4.01.0+dev
2013-08-19 14:42 doligez Note Added: 0010194
2013-08-19 14:42 doligez Target Version 4.01.0+dev => 4.01.1+dev
2014-03-13 10:40 frisch Status acknowledged => resolved
2014-03-13 10:40 frisch Fixed in Version => 4.02.0+dev
2014-03-13 10:40 frisch Resolution open => fixed
2014-03-13 10:40 frisch Assigned To => frisch
2015-12-11 19:25 xleroy Status resolved => closed
2017-02-23 16:35 doligez Category OCaml backend (code generation) => Back end (clambda to assembly)
2017-02-23 16:44 doligez Category Back end (clambda to assembly) => back end (clambda to assembly)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker