Optimization with -inline n

Optimization with -inline n

[John Prevost]

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.

When should I expect to see ocamlopt inlining functions?

jmp

Re: Optimization with -inline n

[Xavier Leroy]

> 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
limitations:
- 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
output.

- Xavier Leroy