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 p7M8Y6bl027612 for ; Mon, 22 Aug 2011 10:34:06 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskBAK8TUk7RVdg2kGdsb2JhbAA4CagLCBQBAQEBCQkNBxQEIYFAAQEBAQMSAiwBGx0BAwwGBQsNLiIBEQEFARwGEwgan3QKjDmCVYQYO4htAgMGgyKDIASHWos6jFk8g2Y X-IronPort-AV: E=Sophos;i="4.68,262,1312149600"; d="scan'208";a="106010952" Received: from mail-qw0-f54.google.com ([209.85.216.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Aug 2011 10:34:00 +0200 Received: by qwc9 with SMTP id 9so5112257qwc.27 for ; Mon, 22 Aug 2011 01:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1cgJoDmAaNAvFLREGjN0QuPiKkPu3p7a5RvI5NW2Si8=; b=px6VXOQqf8bU4fU44kayaP+sPjjQtSN5uVXmMuu9rJ7xC9x2D2itFqK2/Pn2mdPrZ4 3Kg/MpysJZ+RDOs1dg//B/PWWIgJXcaaQMVOW4pmoO5nQWR3E1UoDFhll4FW5H9gbqh8 sC3yUeYvCOHZt3KEb1atsjhcO0H3gNJMiC3GU= MIME-Version: 1.0 Received: by 10.229.31.79 with SMTP id x15mr1180772qcc.12.1314002039284; Mon, 22 Aug 2011 01:33:59 -0700 (PDT) Received: by 10.229.76.229 with HTTP; Mon, 22 Aug 2011 01:33:59 -0700 (PDT) In-Reply-To: <4E520C27.3020205@lexifi.com> References: <4E520C27.3020205@lexifi.com> Date: Mon, 22 Aug 2011 12:33:59 +0400 Message-ID: From: Dmitry Bely To: Alain Frisch Cc: Caml List 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 p7M8Y6bl027612 Subject: Re: [Caml-list] Int32 vs float unboxing On Mon, Aug 22, 2011 at 11:58 AM, Alain Frisch wrote: > On 08/22/2011 09:19 AM, Dmitry Bely wrote: >> >> In the code below "s" reference is unboxed in sum_float loop, but not >> in sum_int32. Why? >> >> let sum_int32 v = >>   let s = ref 0l in >>   for i=0 to (Array.length v)-1 do >>     s := Int32.add !s (Array.unsafe_get v i) >>   done; >>   Int32.add !s Int32.zero >> >> let sum_float v = >>   let s = ref 0. in >>   for i=0 to (Array.length v)-1 do >>     s := !s +. (Array.unsafe_get v i) >>   done; >>   !s +. 0. > > A random guess: since adding Int32.zero is the identity (contrary to adding > 0.), the compiler is clever enough to optimize away this useless operation; > unfortunately, this optimization breaks the unboxing pass. Probably no. If you replace Int32.add !s Int32.zero with Int32.add !s Int32.one s is still boxed. BTW, even zero addition is not optimized away. - Dmitry Bely