Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access to values in nested modules #5573

Closed
vicuna opened this issue Apr 4, 2012 · 3 comments
Closed

Access to values in nested modules #5573

vicuna opened this issue Apr 4, 2012 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Apr 4, 2012

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.

@vicuna
Copy link
Author

vicuna commented Apr 4, 2012

Comment author: pascal_cuoq

This is actually more related (a duplicate, even) of 5537.

@vicuna
Copy link
Author

vicuna commented Apr 4, 2012

Comment author: @gasche

5573 duplicating 5537, that seems fitting.

(I assumed mantis would extend the "related to" relation by transitivity and also display 5537 here, but well.)

@vicuna
Copy link
Author

vicuna commented Aug 19, 2013

Comment author: @damiendoligez

Same questions as for #5537: is this fixed by #5546?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants