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

Jump to bottom

Useless indirection to access a known top-level function #6339

Closed
vicuna opened this issue Mar 6, 2014 · 2 comments
Closed

Useless indirection to access a known top-level function #6339

vicuna opened this issue Mar 6, 2014 · 2 comments
Assignees
@mshinwell
Labels
back-end feature-wish

Comments

@vicuna
Copy link

vicuna commented Mar 6, 2014 •
edited by nojb

Original bug ID: 6339
Reporter: @alainfrisch
Assigned to: @mshinwell
Status: resolved (set by @mshinwell on 2016-12-07T13:03:36Z)
Resolution: fixed
Priority: normal
Severity: feature
Fixed in version: 4.03.0
Category: back end (clambda to assembly)
Tags: patch
Monitored by: @diml @ygrek @jmeber

Bug description

Consider the following piece of code:

let f x = x + 1
let fl l = List.map f l

ocamlopt will compile this structure by putting f and fl into fields of the global symbol corresponding to the current unit, and turn the reference to f (in fl) into a field access of this global symbol. Later in the compilation process (while mapping from lambda to ulambda), the compiler detects that f is actually a constant closure. This information is available (as a Value_closure approximation) when the code for fl is emitted, but there is no way to represent a reference to a known closure in the clambda code. The useless reference (to a statically known value) remains in the generated code as can be seen on the -dcmm or -S output.

The resulting assembly code for fl is:

	movq	%rax, %rbx
	movq	camlTup@GOTPCREL(%rip), %rax
	movq	(%rax), %rax
	jmp	camlList__map_1040@PLT

while it could be:

	movq	%rax, %rbx
	movq	camlTup__3@GOTPCREL(%rip), %rax
	jmp	camlList__map_1040@PLT

Certainly not a big deal, but it should not be too difficult to improve it.

A possible approach would be to treat constant closures (Uclosure(_, [])) as structured constants, allocated during the closure pass.

File attachments
@vicuna
Copy link
Author

vicuna commented Mar 10, 2014

Comment author: @alainfrisch

Attached a diff, which keeps track of constant closure and allows to refer to them directly, thus avoiding some indirections. Moreover, since it considers constant closures as atomic values, they don't prevent inlining. This means that a function such as:

let foo l =
List.map (fun x -> x + 1) l

or

let foo l =
let f x = x + 1 in
List.map f l

can be inlined. This can give a non-negligible speedup (-20% when calling this function foo in a tight loop on an empty list).

Simply avoiding the indirection does not seem to bring much, even on small examples. It might still be a good idea to do so, since reducing the code size is always a good idea.

The patch also detects more cases of closure which don't need their environment.

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

Comment author: @mshinwell

Flambda should fix these problems.

@vicuna vicuna closed this as completed Dec 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mshinwell mshinwell

Labels
back-end feature-wish
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mshinwell @vicuna