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 B0CA97ED5C for ; Wed, 8 Aug 2012 21:29:43 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of fabrissimo@gmail.com) identity=pra; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of fabrissimo@gmail.com designates 209.85.214.182 as permitted sender) identity=mailfrom; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.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-ob0-f182.google.com) identity=helo; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="postmaster@mail-ob0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIBAIe8IlDRVda2kGdsb2JhbABFuVgIIgEBAQEJCQ0bBCOCIAEBAQMBEgIsATgBAwwBBQULDS4hARIBBQEcBhMih1wDBgacUwkDjxSFaCcNiUgBBQyKIWWGYAOTdoFTiwqDKD6BVIIsgVQj X-IronPort-AV: E=Sophos;i="4.77,734,1336341600"; d="scan'208";a="152711415" Received: from mail-ob0-f182.google.com ([209.85.214.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Aug 2012 21:29:42 +0200 Received: by mail-ob0-f182.google.com with SMTP id un3so2975402obb.27 for ; Wed, 08 Aug 2012 12:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SKF7xqxMUr1xglcGkzWhctj+9PP8BwX7kz9qSnGPPbM=; b=p8j0RMFL5QF4RqrA0MHpbUxr3dN5/zeQYIMM1X8BKL9BUe/i5kKsOc994Dj8QHPV6A n/Cdd9ltMXexLtWmu0ehbTzsrDKTXCQafav/HJ7sqKtecQvU48ZNBg4b+l1n2+C4owVG NkPcqo+d//0c/36h/lyS20Elh6KuP2ZGpcOJiiRE9zUOUfoTUB6tFUDqTiDDMwwX+z0c Qw0NmBSYd4Ve8RhhIhjbY3uP9bZVgeWrKpnX7VQy1MegcGyOd+fYGLDHSaHDfJ//1ptU eUEW/02xYGlaAJ4cpjjP3dVd5Oq0Tob2xrAdd+3rSYyaVs8jzwdT0M28VvXyCfPtKiYH g5Og== MIME-Version: 1.0 Received: by 10.182.8.6 with SMTP id n6mr32031591oba.39.1344454182721; Wed, 08 Aug 2012 12:29:42 -0700 (PDT) Sender: fabrissimo@gmail.com Received: by 10.76.3.146 with HTTP; Wed, 8 Aug 2012 12:29:42 -0700 (PDT) In-Reply-To: References: <501F9855.6080709@frisch.fr> <501F9DB9.2050805@frisch.fr> <501FAB4A.107@frisch.fr> <5022A9FE.4050006@frisch.fr> Date: Wed, 8 Aug 2012 21:29:42 +0200 X-Google-Sender-Auth: RkLYE2pktPp67ocbdhH5-XqOzh4 Message-ID: From: Fabrice Le Fessant To: Dmitry Bely Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Compiler bug? On Wed, Aug 8, 2012 at 8:40 PM, Dmitry Bely wrote: >>> I'm not sure, someone else would have to reply! I guess that these >>> registers are supposed to be preserved by the callee in the x64 ABI (and >>> obviously, they don't hold pointers to OCaml values, so they don't have to >>> be tracked by the GC). > > Yes, they should not be tracked by GC, but they may hold some FP > values (can they across GC call?). Actually for x64 FPU registers are > saved; see amd64.S/amd64nt.asm. But not for x86. I'm curious why. MMX registers are not used by OCaml on x86 (except in the SSE2 branch), the backend still uses the x87 stack. I have no x86 computer at hand to check, but I suppose that all temporary floating point values are stored on the C stack by the generated code between floating point computations, for example when calling C functions (including the garbage collector). >> Also, the GC itself will not be using Floating Point code at all, so >> we can save a lot by not saving/restoring these values on the stack. > > This is not entirely true; GC also triggers pending signals processing > that can modify FPU state and calls C library fuctions (e.g. malloc) > that can do anything inside. The kernel is supposed to save all the context before calling signal handlers, otherwise, you would have to disable signals handling during all floating point computations, no ? --Fabrice