Version française
Home     About     Download     Resources     Contact us    
Browse thread
Optimization with -inline n
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: Optimization with -inline n
> 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