0005573: Access to values in nested modules

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0005573

OCaml

OCaml backend (code generation)

public

2012-04-04 20:33

2012-09-21 14:13

Reporter

pascal_cuoq

Assigned To

Priority

low

Severity

tweak

Reproducibility

always

Status

acknowledged

Resolution

open

Platform

OS Version

Product Version

3.12.1

Target Version

4.01.0+dev

Fixed in Version

Summary

0005573: Access to values in nested modules

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.

Tags

No tags attached.

Attached Files

Relationships

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

Notes
(0007281) pascal_cuoq (reporter) 2012-04-04 22:28	This is actually more related (a duplicate, even) of 5537.

(0007282) 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.)

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