Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005537OCamlOCaml backend (code generation)public2012-03-13 20:422014-03-13 10:40
Reportersweeks 
Assigned Tofrisch 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version4.01.1+devFixed in Version4.02.0+dev 
Summary0005537: reducing repeated indirections to access variables in nested modules
DescriptionOCaml'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.
TagsNo tags attached.
Attached Files

- Relationships
related to 0006343resolvedfrisch Making better use of extra slots in the symbol corresponding to the current unit 
has duplicate 0005573resolvedfrisch Access to values in nested modules 
related to 0005546resolvedfrisch moving a function into an internal module slows down its use 

-  Notes
(0008604)
frisch (developer)
2012-12-13 17:09

Probably solved by 0005546.
(0010192)
doligez (administrator)
2013-08-19 14:29

Can anyone confirm that this was fixed by 0005546?
(0010207)
ygrek (reporter)
2013-08-20 13:09

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
(0011026)
frisch (developer)
2014-03-07 15:32

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 0006343, 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.

- Issue History
Date Modified Username Field Change
2012-03-13 20:42 sweeks New Issue
2012-03-20 10:44 gasche Relationship added related to 0005546
2012-03-26 14:41 lefessan Status new => acknowledged
2012-04-04 22:46 gasche Relationship added has duplicate 0005573
2012-07-10 11:28 doligez Target Version => 4.01.0+dev
2012-07-31 13:36 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-21 12:55 doligez Target Version 4.00.1+dev => 4.01.0+dev
2012-12-13 17:09 frisch Note Added: 0008604
2013-08-19 14:29 doligez Note Added: 0010192
2013-08-19 14:29 doligez Assigned To => doligez
2013-08-19 14:29 doligez Status acknowledged => feedback
2013-08-19 14:29 doligez Target Version 4.01.0+dev => 4.01.1+dev
2013-08-20 13:09 ygrek Note Added: 0010207
2013-12-05 15:33 doligez Status feedback => confirmed
2013-12-05 15:33 doligez Assigned To doligez =>
2014-03-07 15:32 frisch Note Added: 0011026
2014-03-07 15:33 frisch Relationship added related to 0006343
2014-03-13 10:40 frisch Status confirmed => 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


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker