From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 9B5527EDC2 for ; Tue, 20 Nov 2012 20:03:24 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of vincent.hugot@gmail.com) identity=pra; client-ip=209.85.212.180; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="vincent.hugot@gmail.com"; x-sender="vincent.hugot@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of vincent.hugot@gmail.com designates 209.85.212.180 as permitted sender) identity=mailfrom; client-ip=209.85.212.180; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="vincent.hugot@gmail.com"; x-sender="vincent.hugot@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wi0-f180.google.com) identity=helo; client-ip=209.85.212.180; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="vincent.hugot@gmail.com"; x-sender="postmaster@mail-wi0-f180.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsFAG7Tq1DRVdS0jWdsb2JhbAA8CYYguywBAQIBAQJ+CBYOAQEBAQkJCwkSBiOCHgEBBAEjFQgBGwIcAwELBgUaAgUhAgIPAQ8CAhEBBQEBGxmHegEDCQYEoTyLYk+BboEKhRkKGScNWYh1AQUMCIEOiippEYE9ghSBEwONM0OGM4JxihaDLz+EEQ X-IronPort-AV: E=Sophos;i="4.83,287,1352070000"; d="scan'208";a="182396784" Received: from mail-wi0-f180.google.com ([209.85.212.180]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Nov 2012 20:03:24 +0100 Received: by mail-wi0-f180.google.com with SMTP id hn14so970845wib.9 for ; Tue, 20 Nov 2012 11:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:organization:message-id:in-reply-to :user-agent; bh=BgomRtmr8IbeOtTVNS2uLyhWmKAsUbsxQ6XUlhyeHys=; b=D9EoDgFIXNq7MFMsjtyFUYj2reN/IjABFqhaMe2LTKRZ6H+p5xbpKAQp6Zpnd0hWmO QFRLbXBdIXTbyuuDS7d1TSN7V+Nv53ds/srh/yKzXtjQyLAcgqh4V+MSFbTGXKDfCy2/ jY38zhcJ0Rs56v0LnImaqwlBJk9Y+Uzj/E0IQM+o5b42OMtyRAQpAdtE6Oways4DYhKD 0TRKwPTJmsSRzPbi0z2Kfyp56KBCxdRH7+5JIXsUae/mkOZEtEnGIZbi/CBNkrxcUd2y ucFQNE6HyOboqxWvyfkQhl+sNSjJosJ3kGH9wMmTabhA9FWuf/CHGd7/ACX0g3m1/3Jm HWqQ== Received: by 10.180.99.36 with SMTP id en4mr16089820wib.20.1353438204105; Tue, 20 Nov 2012 11:03:24 -0800 (PST) Received: from seth (ADijon-156-1-83-178.w90-56.abo.wanadoo.fr. [90.56.2.178]) by mx.google.com with ESMTPS id b1sm21297411wix.11.2012.11.20.11.03.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Nov 2012 11:03:23 -0800 (PST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: caml-list@inria.fr References: <1353347369.78785.YahooMailNeo@web111510.mail.gq1.yahoo.com> <50AA7427.5080104@etorok.net> <1353349126.4420.YahooMailNeo@web111512.mail.gq1.yahoo.com> <20121120112519.2e155a09@crans.org> Date: Tue, 20 Nov 2012 20:03:18 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Vincent HUGOT" Organization: =?utf-8?Q?Universit=C3=A9_de_Franche-Comt=C3=A9?= Message-ID: In-Reply-To: User-Agent: Opera Mail/12.10 (Linux) Subject: Re: [Caml-list] The verdict on "%identity" Is there some place where this fabulous -dmcc switch is documented? ocamlopt's man and --help pages, as well as the manual, are utterly uninformative (either don't mention it or say simply "undocumented"). V. On Tue, 20 Nov 2012 17:19:34 +0100, Gabriel Scherer wrote: > This is good advice in general, and using ocamlobjinfo to get inlining > information from the .cmx is indeed a very good idea. > > Regarding -dcmm vs. -S, I generally use -dcmm myself (much more > readable), but it is not the right tool in this case. The cmm produced > for my test.ml code does make a difference between the three styles: > (let testA/1046 (let x/1075 "camlTest__3" x/1075) > (store (+a "camlTest" 20) testA/1046)) > (let testB/1047 (let prim/1076 "camlTest__2" prim/1076) > (store (+a "camlTest" 24) testB/1047)) > (let testD/1048 "camlTest__1" > (store (+a "camlTest" 28) testD/1048)) > > In fact, the removal of the trivial (let x = foo in x) does not happen > during the inlining passes in closure.ml, but much later at the > register allocation phase, where there is indeed a strong preference > for eg. testA/1046 and x/1705 to be given the same register, and the > useless move is erased. I make no claim of how robust this behavior > will be in a different case (eg. with higher register pressure), but > I'm not sure I really care. > I'd rather have people study the behavior on the compiler the real > performance-critical applications and suggest potential style changes > in the program (or optimization changes in the compiler) in cases > where this really make a performance difference. Writing code in a > certain way because "the generated code is nicer" is usually not worth > the trouble.