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

reducing repeated indirections to access variables in nested modules #5537

Closed
vicuna opened this Issue Mar 13, 2012 · 4 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link
Collaborator

vicuna commented Mar 13, 2012

Original bug ID: 5537
Reporter: sweeks
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:25:49Z)
Resolution: fixed
Priority: normal
Severity: minor
Target version: 4.01.1+dev
Fixed in version: 4.02.0+dev
Category: back end (clambda to assembly)
Has duplicate: #5573
Related to: #5546 #6343
Monitored by: meyer @gasche ronan.lehy@gmail.com dario @ygrek @hcarty @dbuenzli yminsky @yakobowski @alainfrisch

Bug description

OCaml's compilation strategy for variable references in nested modules leaves
around unnecessary field accesses, which are implicit, and not felt by the
programmer.

For example, if I write:

open Core.Std
let f () = Result.ok_unit

the reference to [Result.ok_unit] gets compiled to three field accesses, one for
each dot in [Core.Std.Result.ok_unit]. Furthermore, these accesses happen every
time [f] is called. I think it would typically be prefereable if [f] were
compiled as if it had been written as follows:

let z = Result.ok_unit in
let f = fun () -> z

I think it is surprising to a programmer for variable reference to be such a
non-constant-time operation.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Dec 13, 2012

Comment author: @alainfrisch

Probably solved by #5546.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Aug 19, 2013

Comment author: @damiendoligez

Can anyone confirm that this was fixed by #5546?

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Aug 20, 2013

Comment author: @ygrek

Anticonfirmed..

module Z = struct
module A = struct
let a = [1;2;3]
end
end

open Z.A

let access () = a

On the above code ocamlopt 4.02.0+dev0-2013-06-13 generates :

camlA__access_1012:
.cfi_startproc
.L100:
movq camlA@GOTPCREL(%rip), %rax
movq (%rax), %rax
movq (%rax), %rax
movq (%rax), %rax
ret
.cfi_endproc

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Mar 7, 2014

Comment author: @alainfrisch

The current trunk would compile the code from ygrek to:

camlFoo__access_1012:
.cfi_startproc
.L100:
movq camlFoo__3@GOTPCREL(%rip), %rax
ret
.cfi_endproc

since the value is known structured constant.

If we replace the constant [1;2;3], with, say "Random.int 100", we still get the access code reported by ygrek. With the patch from #6343, we get instead:

camlFoo__access_1012:
.cfi_startproc
.L100:
movq camlFoo@GOTPCREL(%rip), %rax
movq 24(%rax), %rax
ret
.cfi_endproc

which indeed eliminates the two extra indirections corresponding to the two nesting levels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.