You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered: