Re: [Caml-list] a question about "ocamlopt" and "ocamldep"

[Gabriel Scherer <gabriel.scherer@gmail.com>]

> to build a module,
> you only need the *interfaces* of its dependencies, but it is unfortunately
> not ensured when compiling to native code

It is actually possible to have separate compilation for .cmx, just
like for .cmo: when ocamlopt looks for the .cmx for a given
dependency, if it doesn't find it, it doesn't optimize, and doesn't
record it as a dependency. So by selectively removing .cmx from your
compilation environment, you can ensure to have only
interface-dependency on some modules -- at the cost of disabled
optimizations, of course.

(I seem to remember that may happen in particular when you compile
against certain libraries that do not distribute the .cmx separately.)

> I wonder now if it would be theoretically possible to do these optimization,
> not at compile-time, but delay them until link-time, when the code is fully
> known...

Well, you could always recompile just before you want to link. What is
usually called "link-time optimizations" are optimizations that are
convenient to perform on the compiled objects directly (those that the
linkers see). The high-level inlining or memory representation
prediction optimizations are really part of "compilation" (but *when*
you compile in the lifetime of your project is up to you; you could
always distribute source only and compile just before running the
program, without saving the result).

On Tue, Mar 13, 2012 at 7:34 PM, Matthias Puech <puech@cs.unibo.it> wrote:
> Hello,
>
> This is consistent with how ocamlc/ocamlopt work: separate compilation is
> ensured the way you think by bytecode .cmo compilation: to build a module,
> you only need the *interfaces* of its dependencies, but it is unfortunately
> not ensured when compiling to native code, because of the global
> (inter-modules) optimizations performed (inlining AFAIK). Thus, to build a
> .cmx module, you need to be aware of the actual *code* of its dependencies.
>
> I wonder now if it would be theoretically possible to do these optimization,
> not at compile-time, but delay them until link-time, when the code is fully
> known...
>
> Cheers,
>    -m
>
> Le 03/13/2012 07:19 PM, Matej Košík a écrit :
>
>> Hi,
>>
>> The "ocamldep" tool generates Makefile dependencies for both situations:
>> - when we use "ocamlc"
>> - as well as when we use "ocamlopt"
>>
>> Dependencies, generated for "*.cmo" files,
>> are corresponding "*.cmi" files.
>>
>> This is not surprising.
>>
>> However, dependencies, generated for "*.cmx" files,
>> are always other "*.cmx" files.
>>
>> This is surprising.
>>
>> Why "*.cmx" files do not depend on "*.cmi" files?
>>
>> I have noticed this in a bigger project but this phenomenon appear to
>> happen for arbitrarily small projects.
>>
>> Consider the following ocamldep-generated couple of rules:
>>
>> src/ml2c/typing/printtyp.cmo: src/ml2c/typing/types.cmi \
>>     src/ml2c/typing/primitive.cmi src/ml2c/typing/predef.cmi \
>>     src/ml2c/typing/path.cmi src/ml2c/typing/outcometree.cmi \
>>     src/ml2c/typing/oprint.cmi src/ml2c/utils/misc.cmi \
>>     src/ml2c/parsing/longident.cmi src/ml2c/typing/ident.cmi \
>>     src/ml2c/typing/env.cmi src/ml2c/typing/ctype.cmi \
>>     src/ml2c/utils/clflags.cmi src/ml2c/typing/btype.cmi \
>>     src/ml2c/parsing/asttypes.cmi src/ml2c/typing/printtyp.cmi
>> src/ml2c/typing/printtyp.cmx: src/ml2c/typing/types.cmx \
>>     src/ml2c/typing/primitive.cmx src/ml2c/typing/predef.cmx \
>>     src/ml2c/typing/path.cmx src/ml2c/typing/outcometree.cmx \
>>     src/ml2c/typing/oprint.cmx src/ml2c/utils/misc.cmx \
>>     src/ml2c/parsing/longident.cmx src/ml2c/typing/ident.cmx \
>>     src/ml2c/typing/env.cmx src/ml2c/typing/ctype.cmx \
>>     src/ml2c/utils/clflags.cmx src/ml2c/typing/btype.cmx \
>>     src/ml2c/parsing/asttypes.cmx src/ml2c/typing/printtyp.cmi
>>
>> The second rule seems to be unnecessarily demanding (unless it makes no
>> sense to compile *.cmi files if we use ocamlopt). It should read:
>>
>> src/ml2c/typing/printtyp.cmx: src/ml2c/typing/types.cmi \
>>     src/ml2c/typing/primitive.cmi src/ml2c/typing/predef.cmi \
>>     src/ml2c/typing/path.cmi src/ml2c/typing/outcometree.cmi \
>>     src/ml2c/typing/oprint.cmi src/ml2c/utils/misc.cmi \
>>     src/ml2c/parsing/longident.cmi src/ml2c/typing/ident.cmi \
>>     src/ml2c/typing/env.cmi src/ml2c/typing/ctype.cmi \
>>     src/ml2c/utils/clflags.cmi src/ml2c/typing/btype.cmi \
>>     src/ml2c/parsing/asttypes.cmi src/ml2c/typing/printtyp.cmi
>>
>> Shouldn't it?
>>
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>