[Caml-list] Inlining across functors (was: O'Caml vs C++: a little benchmark)

[Thorsten Ohl <ohl@physik.uni-wuerzburg.de>]

Xavier Leroy <xavier.leroy@inria.fr> writes:

> Just for the record: ocamlopt does perform inlining across
> compilation units (via the information stored in .cmx files).  What
> it doesn't do, however, is inlining and specialization of recursive
> function definitions.

However, it appears that it doesn't inline across functors.  For
example, in

  module type M = 
    sig
      type t
      val op : t -> t -> t
      val of_int : int -> t
      val to_int : t -> int
    end
  
  module M : M =
    struct
      type t = int
      let op = ( + )
      let of_int n = n
      let to_int n = n
    end
  
  module F (A : M) =
    struct
      let f a b = A.to_int (A.op  (A.of_int a) (A.of_int b))
    end
  
  module M1 =
    struct
      let f1 a b = M.to_int (M.op  (M.of_int a) (M.of_int b))
    end
      
  module M2 =
    struct
      module FM = F(M)
      let f2 a b = FM.f a b
    end

all functions used in M1.f1 are expanded inline

  *** Linearized code
  Opt_f1_66:
    n/10[%eax] := a/8[%eax] + b/9[%ebx] + -1
    return R/0[%eax]

while M2.f2 retains a lot of auxiliary code:
  
  *** Linearized code
  Opt_f2_72:
    spilled-a/30[s0] := a/8[%eax] (spill)
    b/9[%eax] := R/1[%ebx]
    A/11[%ebx] := [env/10[%ecx] + 12]
    env/12[%ecx] := [A/11[%ebx]]
    spilled-env/29[s1] := env/12[%ecx] (spill)
    A/13[%ebx] := [env/12[%ecx] + 12]
    fun/14[%ebx] := [A/13[%ebx] + 8]
    spilled-fun/27[s3] := fun/14[%ebx] (spill)
    A/15[%ebx] := [env/12[%ecx] + 12]
    fun/16[%ebx] := [A/15[%ebx] + 4]
    A/17[%ecx] := [fun/16[%ebx]]
    {spilled-fun/27[s3]* spilled-env/29[s1]* spilled-a/30[s0]*}
    R/0[%eax] := call A/17[%ecx]
    R/0[%eax]
    R/1[%ebx]
    A/28[s2] := A/18[%eax] (spill)
    env/31[%eax] := spilled-env/29[s1] (reload)
    A/19[%eax] := [env/31[%eax] + 12]
    fun/20[%ebx] := [A/19[%eax] + 4]
    A/21[%ecx] := [fun/20[%ebx]]
    a/32[%eax] := spilled-a/30[s0] (reload)
    {spilled-fun/27[s3]* A/28[s2]* spilled-env/29[s1]*}
    R/0[%eax] := call A/21[%ecx]
    R/0[%eax]
    R/1[%ebx]
    env/33[%ebx] := spilled-env/29[s1] (reload)
    A/23[%ebx] := [env/33[%ebx] + 12]
    A/24[%ecx] := [A/23[%ebx]]
    A/34[%ebx] := A/28[s2] (reload)
    {spilled-fun/27[s3]*}
    R/0[%eax] := call "caml_apply2" R/0[%eax]
    R/1[%ebx]
    R/2[%ecx]
    fun/35[%ebx] := spilled-fun/27[s3] (reload)
    A/26[%ecx] := [fun/35[%ebx]]
    tailcall A/26[%ecx]
    R/0[%eax]
    R/1[%ebx]

Is this because the signature M can make no guarantee that op is never
a recursive function? Do all functor applications fall under the `no
inlining and specialization of recursive function definitions' clause?

Cheers,
-Thorsten
-- 
Thorsten Ohl, Physics Dept., Wuerzburg Univ. -- ohl@physik.uni-wuerzburg.de
http://theorie.physik.uni-wuerzburg.de/~ohl/     [<=== PGP public key here]
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners