Re: Optimization with -inline n

From: Xavier Leroy (
Date: Mon Feb 01 1999 - 14:27:42 MET

Date: Mon, 1 Feb 1999 14:27:42 +0100
From: Xavier Leroy <>
To: John Prevost <>,
Subject: Re: Optimization with -inline n
In-Reply-To: <>; 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