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

[patch] Generate direct call inside inlined function #5917

Closed
vicuna opened this issue Feb 11, 2013 · 1 comment
Closed

[patch] Generate direct call inside inlined function #5917

vicuna opened this issue Feb 11, 2013 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Feb 11, 2013

Original bug ID: 5917
Reporter: @chambart
Assigned to: @chambart
Status: closed (set by @xavierleroy on 2017-09-24T15:33:17Z)
Resolution: fixed
Priority: normal
Severity: feature
Target version: undecided
Category: back end (clambda to assembly)
Tags: patch
Related to: #5894
Monitored by: @gasche mfp @ygrek @jmeber @hcarty @Chris00 @alainfrisch

Bug description

Currently when a function is inlined calls inside its body are not converted to direct call
when it is possible. For instance:

let f x = x + x

let g h (x,y) = h x, h y

let i (x,y) = g f (x,y)

When i is compiled, g will be inlined giving:

let i (x,y) = f x, f y

but calls to f will be generic calls (in that particular case it could even be inlined).

To do that, this pach add an environment of approximate values to the Closure.substitute
function to be able to retrieve the function definition at call site.

This also prepare for future patch using that environment: there are many possible things
that can be improved in functions when approximate environment is known. Normally this is
not really important because usually the programmer will avoid writing stupid code, but
when a function body is inlined, it can become redundant.

I also would like to open a discution: should we separate closure conversion and constant
propagation in two different passes ?

If we add other optimisations to the constant propagation phase, we would need to implement
them both inside the close (lambda to clambda) and substitute (clambda to clambda) functions.
So I think it would probably be simpler to simplify the closure conversion and do only that
in the lambda to clambda pass and do a separate optimisation pass on the produced clambda
code.

Additional information

Since the evaluation of function size for inlining is considered on the body without the
potential inline, it can be innacurate and lead to code size explosition in contrieved
examples like:

let f1 x = x + x
let f2 g (a,b) = g a, g b
let f3 g1 g2 (a,b) = g1 g2 (a,b), g1 g2 (a,b)
let f4 g1 g2 g3 (a,b) = g1 g2 g3 (a,b), g1 g2 g3 (a,b)

let f = f4 f3 f2 f1 (1,1)

If this bother someone, it is simple to forbid that by adding a limit to depth of allowed
inlining.

This patch may be used to improve the patch submited for issue #5894.

File attachments

@vicuna
Copy link
Author

vicuna commented Aug 3, 2016

Comment author: @chambart

This was something that originally led to develop flambda. The feature was introduced in 4.03.

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