Date: Mon, 1 Feb 1999 14:27:42 +0100
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: John Prevost <firstname.lastname@example.org>, email@example.com
Subject: Re: Optimization with -inline n
In-Reply-To: <firstname.lastname@example.org>; from John Prevost on Thu, Jan 28, 1999 at 04:58:42AM -0500
> In what circumstances will ocamlopt -inline n put a function in-line?
> I was just trying it to see what effect it could have on my monadic
> parsing libraries, but it didn't seem to have much effect, whereas my
> inlining by hand did. I take this to mean that it does not, at least,
> cross module boundaries.
Inlining does cross module boundaries. However, it has the following
- functions defined recursively are not inlined;
- when inlining higher-order functions with known function arguments,
those known function arguments are not themselves inlined.
The latter limitation is unfortunate, as it means that only
"first-order" code can really benefit from inlining, however it's not
yet clear to me how to remove this limitation within the limits
of the current implementation of inlining.
> When should I expect to see ocamlopt inlining functions?
For each function definition, ocamlopt estimates the size of the
function body (in instructions -- this is a fairly approximative
computation). If the size is less than the <n> parameter to
ocamlopt -inline <n>, the function is marked inlinable.
If you're curious to see what has been actually inlined, you
can compile with ocamlopt -S and look at the generated assembly code,
or (slightly more readable) compile with ocamlopt -dcmm; this causes
the first intermediate code after inlining to be dumped on standard
- Xavier Leroy
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:19 MET