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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 0E58B7ED67 for ; Tue, 14 Aug 2012 09:11:58 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of benedikt.meurer@googlemail.com) identity=pra; client-ip=74.125.82.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="benedikt.meurer@googlemail.com"; x-sender="benedikt.meurer@googlemail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of benedikt.meurer@googlemail.com designates 74.125.82.182 as permitted sender) identity=mailfrom; client-ip=74.125.82.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="benedikt.meurer@googlemail.com"; x-sender="benedikt.meurer@googlemail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-we0-f182.google.com) identity=helo; client-ip=74.125.82.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="benedikt.meurer@googlemail.com"; x-sender="postmaster@mail-we0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEBAOT5KVBKfVK2kGdsb2JhbABFugYIIgEBAQEJCQ0bBCOCIAEBAQMBEgImBgEBNwEECwsLAyYSNAEFARwGNYdbAQMGBgSZUwkDimaELwEFhgkKQA2JSAaLEoVRYJVOgRSNHz6EAA X-IronPort-AV: E=Sophos;i="4.77,764,1336341600"; d="scan'208";a="153028860" Received: from mail-we0-f182.google.com ([74.125.82.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 14 Aug 2012 09:11:57 +0200 Received: by weyx56 with SMTP id x56so73206wey.27 for ; Tue, 14 Aug 2012 00:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=UVxajDj1A7Z7iF0bzVoOuTuFGVUJu/OWbQMjT5wBGdY=; b=G3a7mGjMU05NP5kerKay35ignSRXi6TFclPzqTgWk5SMJjwler4jmP+Yn2aFUWNzt8 HbXxSKMKx11zDHRTnO8qlTm8cO+nu2vlRacBm469HZP+ISdOqA7+6gzgXUY1B7v/g3gl nXldlpsVDcJcuK9otJz5zIl7POfjKphPB1L9QSTXTeC6bmPPYZRqXP1PP0An9I2sV/w/ G/xFzyt6e/5GuWFoKkWsUhjtzOrgKFdUDmHbf1767f+FpRX2CYNohN5mO8gVBi472QSk AkD1FxZ4buKJPwMWumorkWS+a/cjvXoSxhdIR30+RGguJBAo/Z5kMhd7io7RXHzrVXMO Q4vA== Received: by 10.180.79.229 with SMTP id m5mr25310055wix.13.1344928316746; Tue, 14 Aug 2012 00:11:56 -0700 (PDT) Received: from tatooine.in.benediktmeurer.de (sign-4d094259.pool.mediaWays.net. [77.9.66.89]) by mx.google.com with ESMTPS id w7sm20832532wiz.0.2012.08.14.00.11.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 00:11:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Benedikt Meurer In-Reply-To: Date: Tue, 14 Aug 2012 09:11:53 +0200 Cc: Benedikt Meurer , Caml List Content-Transfer-Encoding: quoted-printable Message-Id: <401723D2-9388-4FFF-8E7A-D741ED111E64@gmail.com> References: <51E93001-B3AB-4B8D-B46C-7ACA11346C38@psellos.com> To: Jeffrey Scofield X-Mailer: Apple Mail (2.1278) Subject: [Caml-list] Re: ARM code generator problem On Aug 13, 2012, at 21:21 , Jeffrey Scofield wrote: > OCamlers, Benedikt: Hey Jeffrey, >>> The result is that a value in d7 is sometimes destroyed by a use of s14 >>> as a scratch register. In my code it was a call to float_of_int that >>> destroyed a float value being kept in d7. >>=20 >> If you look at destroyed_at_oper in asmcomp/arm/proc.ml, you'll see that >> d7 (s14+s15) is marked as destroyed for those operations where it is >> used as scratch register. >=20 > I was able to reproduce this behavior with the stock OCaml 4.00.0 compile= r, > so I really do think there's a problem. >=20 > I whittled my code down to just a few lines. Here it is: >=20 > let rate_pos scounts : float =3D > let m_MIN =3D -999.0=20 > in let max1s =3D Array.make 14 m_MIN > in let max2s =3D Array.make_matrix 14 14 m_MIN > in let try_build (k1: int) (m: float) : unit =3D > let denom =3D 12 > in let try1b (sawk1, xct) k =3D > let () =3D > if max2s.(k1).(k) > m then > let adjm =3D if m <=3D m_MIN then 0.0 else m > in let numer =3D > if k =3D k1 then 48 > else if sawk1 then 36 > else 24 > in let f =3D float_of_int numer /. float_of_int de= nom > in let () =3D > if max1s.(k1) <=3D m_MIN then max1s.(k1) <- 0.0 > in > max1s.(k1) <- > max1s.(k1) +. (max2s.(k1).(k) -. adjm) *. f > in > if k =3D k1 then > (true, xct) > else > (sawk1, xct + scounts.(k)) > in > ignore (List.fold_left try1b (false, 0) []) > in let () =3D Array.iteri try_build max1s > in > 0.0 >=20 > (This is a heavily hacked up piece of an evaluation function for a card > game app.) >=20 > Here is my OCaml command line (running on Linux/ARM inside Qemu, as you > suggested--it works!): >=20 > $ ocamlopt -ffpu vfpv3 -c -S rate.ml >=20 > I'm using vfpv3 because that's what I use for my iOS port. The system > type is linux_eabihf, which is what you need to get vfpv3 support. >=20 > The section that seems to misbehave is these three lines: >=20 > in let f =3D float_of_int numer /. float_of_int denom > in let () =3D > if max1s.(k1) <=3D m_MIN then max1s.(k1) <- 0.0 >=20 > Here is the assembly code with added annotations: >=20 > ldr r12, [r2, #16] @ r12 <- m_MIN block > mov r0, r7, asr #1=20=20=20=20 > ldr r7, [r2, #20] > movs r6, #0xc @ r6 <- denom > fmsr s14, r6=20=20=20=20=20=20=20=20=20=20=20 > fsitod d10, s14 @ d10 <- float_of_int denom > ldr r6, [r7, #-4] > fldd d7, [r12, #0] @ d7 <- m_MIN > ldr r12, [r2, #28] > fmsr s14, r0 @ *** d7 is destroyed here *** > fsitod d9, s14 @ d9 <- float_of_int numer > cmp r12, r6, lsr #10 > bcs .L111 > add r6, r7, r12, lsl #2 > fldd d6, [r6, #-4] @ d6 <- max1s.(k1) > fdivd d8, d9, d10 > fcmpd d6, d7 @ *** This comparison fails *** > fmstat > bhi .L104 >=20 > I built the OCaml 4.00.0 compiler from sources inside Qemu. The > line for configure was just this: >=20 > $ ./configure --host armv5tejl-unknown-linux-gnueabihf >=20 > After that, I just built as usual. >=20 > If you agree that this is a problem, I can create a Mantis > bug report for it (if you like). Jep, that's a bug indeed. Somewhow ocamlopt seems to believe that the Ifloa= tofint instruction preserves d7 although it is marked as destroyed for this= operation. > Best regards, > Jeffrey greets, Benedikt=