Re: [Caml-list] two unrelated questions

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> 1.  What is the right "functional pattern" for early-outing on success
>     while using an iter/map/fold type function?
>     Is throwing an exception the best bet?

I believe so.

> 2.  I'm confused as to when the compiler decides to inline and when it
>     doesn't.  None of the calls in the following program get inlined,
>     regardless of the value of -inline in ocamlopt.

It's an embarrassing example of two distinct optimizations that
conflict, resulting in bad code :-)  

The first optimization is that constant data structures, such as the
tuple (1,2) in your example, are pre-built at compile-time rather than
dynamically built at run-time.  So, by the time we get to the inliner,
the "a" value is no longer syntactically a pair, but some sort of
special constant.

The second optimization is the tupled function optimization,
whereas functions taking a N-tuple of arguments are replaced by a
function taking N arguments.  Such functions are inlined only when
applied to an argument that is syntactically a N-tuple.  Otherwise,
the "slow path" (that takes a real tuple as argument, fetches
its N components, and jumps to the fast entry point) is followed, and
this turns inlining off.

You would get inlining in your example after rewriting it like this,
for instance:

> let myfst (a,b) = a
> let mysnd (a,b) = b
> 
> let myfsti ((a,b):int*int) = a
> let mysndi ((a,b):int*int) = b
>     
> let f x y =
>   myfst (x,y) + 1;
>   1 + mysnd (x,y);
>   myfsti (x,y);
>   mysndi (x,y)
>
> let _ = f 1 2

I agree this behavior is surprising and should be fixed at some point.

> (and after running dumpobj on the bytecode and
> looking at the asm from ocamlopt, we went and saw with dismay how
> Pervasives.fst and .snd are builtins and not inlined functions)

The bytecode compiler performs no inlining at all.  This is the main
reason why fst and snd are builtins (so that they do not generate
function calls in bytecoded programs).

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr