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 p3T8vtdP016915 for ; Fri, 29 Apr 2011 10:57:55 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYDALp8uk3RVdg2i2dsb2JhbACYSY0zCBQBAQEKCwsHEgYhqSyKfIInhSc0iF4BAQMGhXgEhgeIYYgRgiM7gzA X-IronPort-AV: E=Sophos;i="4.64,286,1301868000"; d="scan'208";a="94061978" Received: from mail-qw0-f54.google.com ([209.85.216.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Apr 2011 10:57:50 +0200 Received: by qwc9 with SMTP id 9so2897862qwc.27 for ; Fri, 29 Apr 2011 01:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=WfokDbDPHDaVysT8gYMVErHtP2l4FSca+5v+Qkr7lqA=; b=e2p8W/ZVqts2SP6s5jmWo1lipz8JT+Ke5Cx4/Be21FVPkkh12ncciNeY3u4l/haKUK FimpocgXlJqLHqjNU/FfUv/pZHgaOYI3eDHQXL2KyO+yoOrcp0fKPfzZlDw97VWGohzW on3ZHExQYlqD+QLzAY0lHHJ2bIsWvomtn4FgA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=lpBYnklkHaCvEdL4dpIN0uYz9d/04Xr4TdNd3Cdp4NdPWCgPFY9Yc66GGPksfc8AAD 83rml84qmcnnl1zBON/2d5LdYbBhpT/St084UX0Uen8Nq4X2cqRuq0wupETAr1oJKj86 K4xf0pV2DKmHvCB1Gvo/huko3yWtGyW53jgcQ= MIME-Version: 1.0 Received: by 10.229.5.199 with SMTP id 7mr3516680qcw.229.1304067468758; Fri, 29 Apr 2011 01:57:48 -0700 (PDT) Received: by 10.229.32.1 with HTTP; Fri, 29 Apr 2011 01:57:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Apr 2011 12:57:48 +0400 Message-ID: From: Dmitry Bely To: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3T8vtdP016915 Subject: Re: [Caml-list] Comparing variant types On Thu, Apr 28, 2011 at 11:16 PM, Ethan Burns wrote: > Hi, > > I have a program that uses variant types as an enumeration.  While > profiling, I noticed that compare_val was being called a bunch.  When > I went to inspect why this was the case, it turns out that it was > being called to compare equality of my variants.  I am a bit confused, > however, because my understanding was that variants that are declared > without an 'of' clause were just represented as integers and therefore > a type containing only these simple elements should be directly > comparable (no compare_val). > > While looking further into this, I found a little example where the > compiler seems to produce a simple comparison in one case and not in > another: > > type dir = Left | Right | Up | Down | No_op > > (* performs a simple comparison *) > let f a = a <> Right > > (* calls out to C to do compare_val *) > let g (a:dir) b = a <> b > > There is the -dlambda output: > > (seq >  (let (f/69 (function a/70 (!= a/70 1a))) >    (setfield_imm 0 (global Test!) f/69)) >  (let (g/71 (function a/72 b/73 (caml_notequal a/72 b/73))) >    (setfield_imm 1 (global Test!) g/71)) >  0a) > > Since both functions know that the types of the elements being compare > is 'dir', which contains only simple elements, why does the g function > still use compare_val?  Does the compiler not perform this particular > optimization? I don't know why structured compare is not optimized, but physical one (which does the same in your case) is optimized away as expected. let g (a:dir) b = a != b - Dmitry Bely