From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2DJRGTa003894 for ; Tue, 13 Mar 2012 20:27:16 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswBALKeX09KfVM2kGdsb2JhbABDhTqeZ5FCCCIBAQEBCQkNBxQEI4IJAQEBAwESAg8dARsSCwEDAQsGAwILDQICCR0CAiIBEQEFAQoSBhMSEIdjBQueMQqLMkyCcYUXP4h0AQULgSSOIIEWBJVQjkU9hAc X-IronPort-AV: E=Sophos;i="4.73,578,1325458800"; d="scan'208";a="135892249" Received: from mail-ee0-f54.google.com ([74.125.83.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Mar 2012 20:27:10 +0100 Received: by eekd17 with SMTP id d17so829091eek.27 for ; Tue, 13 Mar 2012 12:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=7spfTGRyciIhU1hsQS6h5ejcvNx/x/4mS6X820M9ROY=; b=aAcOVJdghfceUE8qhr1ks6dkhgM/1fr7UWvvwpZOpnO8ZTZv8jGqCIYW17Kkj4rclI dpkJdsn7NZf/XF3qPE7w9CfexwgdLK24sJyHYiS6rhb7LRHovX5qcNd6XZVt+ERMHkP0 THndKa6O3u/x3Gpt5qSEFhr9afVDM6ijDPPlFU87QOnO+EKwCtlTcRJlCPT0jYwxvucF SKFeGbvRLtP9c+9KkDeVmFWx7rSeJr2MJAy+g3b9sfAjoDcMyZCR40cIgPI0F5aa8Ps8 jshnoRuqE8Zk2gtQmIL1w3X0KOsQzTNXw8dDnfQ00gHcSMCtZ3ZWC+kGYnEszFOFs2Ny vZvA== Received: by 10.50.170.41 with SMTP id aj9mr6595940igc.56.1331666830186; Tue, 13 Mar 2012 12:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.3.38 with HTTP; Tue, 13 Mar 2012 12:26:30 -0700 (PDT) In-Reply-To: <4F5F9342.4030104@cs.unibo.it> References: <4F5F8FBD.5060205@gmail.com> <4F5F9342.4030104@cs.unibo.it> From: Gabriel Scherer Date: Tue, 13 Mar 2012 20:26:30 +0100 Message-ID: To: Matthias Puech Cc: caml-list@inria.fr, 5764c029b688c1c0d24a2e97cd764f@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q2DJRGTa003894 Subject: Re: [Caml-list] a question about "ocamlopt" and "ocamldep" > 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 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 >