From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jeffsco@psellos.com>
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 C78A17ED67
	for <caml-list@sympa.inria.fr>; Fri, 10 Aug 2012 23:41:49 +0200 (CEST)
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  jeffsco@psellos.com) identity=pra; client-ip=174.121.218.178;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="jeffsco@psellos.com";
  x-sender="jeffsco@psellos.com"; x-conformance=sidf_compatible
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  jeffsco@psellos.com) identity=mailfrom;
  client-ip=174.121.218.178;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="jeffsco@psellos.com";
  x-sender="jeffsco@psellos.com"; x-conformance=sidf_compatible
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@pse.psellos.com) identity=helo;
  client-ip=174.121.218.178;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="jeffsco@psellos.com";
  x-sender="postmaster@pse.psellos.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAMx4JVCuedqy/2dsb2JhbABEuXeBB4JOEz+BPi6Hcgu3a4sPhgRgA4hOjg+ESIozgn8
X-IronPort-AV: E=Sophos;i="4.77,748,1336341600"; 
   d="scan'208";a="169618117"
Received: from pse.psellos.com ([174.121.218.178])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Aug 2012 23:41:48 +0200
Received: from [192.168.0.23] (71-212-116-164.tukw.qwest.net [71.212.116.164])
	(authenticated bits=0)
	by pse.psellos.com (8.13.8/8.13.8) with ESMTP id q7ALfiDF018264
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Fri, 10 Aug 2012 16:41:45 -0500
Content-Transfer-Encoding: 7bit
From: Jeffrey Scofield <jeffsco@psellos.com>
Content-Type: text/plain; charset=us-ascii
Message-Id: <51E93001-B3AB-4B8D-B46C-7ACA11346C38@psellos.com>
Date: Fri, 10 Aug 2012 14:41:43 -0700
Cc: Jeffrey Scofield <jeffsco@psellos.com>
To: Caml List <caml-list@inria.fr>
Mime-Version: 1.0 (Apple Message framework v1280)
X-Mailer: Apple Mail (2.1280)
X-Validation-by: jeffsco@psellos.com
Subject: [Caml-list] ARM code generator problem

Greetings,

While working on porting OCaml 4.00.0 to iOS, I ran across
what looks like a problem in the ARM code generation.

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:

    | Lop(Ifloatofint) ->
        `       fmsr    s14, {emit_reg i.arg.(0)}\n`;
        `       fsitod  {emit_reg i.res.(0)}, s14\n`; 2

Note that the emitted code always uses s14 (unconditionally).  This
suggests that s14 should be set aside as a scratch register.

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.

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.

I'm wondering if there's any wisdom on the list about this problem.
I don't see anything about it on Mantis.

For my own project, I think I can solve this simply by leaving d7 out of
the list of general registers in proc.ml.  However, this might be a bit
drastic.  Maybe there is a more subtle and wise solution.

You can read about OCaml4-on-iOS progress in my sporadic blog:

    http://psellos.com/2012/07/2012.07.ocamlxarm-ocaml4-1.html

I can provide my OCaml code and the generated ARM code if it will help
show the problem.  I haven't (yet) tried to whittle it down to a small
case.

Regards,

Jeffrey