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 54E7B7ED6E for ; Sat, 11 Aug 2012 10:00:02 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of benedikt.meurer@googlemail.com) identity=pra; client-ip=209.85.214.54; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="benedikt.meurer@googlemail.com"; x-sender="benedikt.meurer@googlemail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of benedikt.meurer@googlemail.com designates 209.85.214.54 as permitted sender) identity=mailfrom; client-ip=209.85.214.54; receiver=mail1-smtp-roc.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 (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-bk0-f54.google.com) identity=helo; client-ip=209.85.214.54; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="benedikt.meurer@googlemail.com"; x-sender="postmaster@mail-bk0-f54.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQCAA8QJlDRVdY2k2dsb2JhbABEuXEIIgEBAQEJCQsJFAQjgiABAQEDARICExMGAQE3AQQLCwsDJhI0AQUBHAY1h1sBAwYGBJk8CQOKZoQvAQWFDQpADYlIBosPhVFglU6BFI0ePoQA X-IronPort-AV: E=Sophos;i="4.77,749,1336341600"; d="scan'208";a="169643020" Received: from mail-bk0-f54.google.com ([209.85.214.54]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Aug 2012 10:00:01 +0200 Received: by bkcje9 with SMTP id je9so1098665bkc.27 for ; Sat, 11 Aug 2012 01:00:01 -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=KeOq1b4bhlkaaKGDINPOY+dhy6xDl5l2k3YVB+IBMhk=; b=GblmYUYUQOofPaeGb2zJcP8Z+RiFy0pyxP6+iJQaqB8oDS2URTQ5HYpwGeMqEv2j6e du90mTcKS0aKJoMO/Yz+1nlCDXlXzp8IM5BTl5UEzkRd5bL26ixCdW5vBKHx7g4u352Z evDn3NvPzntt7M607Q5BnLAxQ4cFgSXXre5XpxOSn7VSqd6cUK05+2og0o5IWuCaKDQi BgR0tIrjPaDHQTPwkBCO2hCgBG+rR3aJIqwocGUY9a7PFzHtv2oy5Z0srZKPlPpNTK1J i3S4JSmfHZCnmAHIsftYJsdN7UDHvB2ZJq8YHimkNHwOkoz8YnFIP0czR8WDLP5t8KVT +Yrw== Received: by 10.205.136.3 with SMTP id ii3mr2031217bkc.101.1344672000919; Sat, 11 Aug 2012 01:00:00 -0700 (PDT) Received: from tatooine.in.benediktmeurer.de (sign-4db6014b.pool.mediaWays.net. [77.182.1.75]) by mx.google.com with ESMTPS id c18sm362281bkv.8.2012.08.11.00.59.59 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Aug 2012 01:00:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Benedikt Meurer In-Reply-To: <51E93001-B3AB-4B8D-B46C-7ACA11346C38@psellos.com> Date: Sat, 11 Aug 2012 10:00:06 +0200 Cc: Caml List Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E93001-B3AB-4B8D-B46C-7ACA11346C38@psellos.com> To: Jeffrey Scofield X-Mailer: Apple Mail (2.1278) Subject: Re: [Caml-list] ARM code generator problem On Aug 10, 2012, at 23:41 , Jeffrey Scofield wrote: > Greetings, Hey Jeffrey, > While working on porting OCaml 4.00.0 to iOS, I ran across > what looks like a problem in the ARM code generation. >=20 > If you look at asmcomp/arm/emit.mlp you see lots of places where > s14 is used as a scratch register. The one that showed up in my > code is the code sequence for float_of_int: >=20 > | Lop(Ifloatofint) -> > ` fmsr s14, {emit_reg i.arg.(0)}\n`; > ` fsitod {emit_reg i.res.(0)}, s14\n`; 2 >=20 > Note that the emitted code always uses s14 (unconditionally). This > suggests that s14 should be set aside as a scratch register. >=20 > However, s14 is also an alias for the low order part of d7. If you look > at asmcomp/arm/proc.ml you'll see that d7 is used as a general purpose > register. >=20 > 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. 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. If possible, it would probably also make sense to merge some of the iOS rel= ated code into the upstream ARM backend, in case you are interested. > Regards, > Jeffrey greets, Benedikt=