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 67C827ED5C for ; Thu, 9 Aug 2012 02:53:51 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.161; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.161 as permitted sender) identity=mailfrom; client-ip=134.160.33.161; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.161 as permitted sender) identity=helo; client-ip=134.160.33.161; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIBAN0II1CGoCGhmWdsb2JhbABFhgG0AwEBAQEBCAsLGyeCIAEBBAEjFUARCxgCAgUWCwICCQMCAQIBRRMGAgEBiAMGqFCTGYEhiXGDRIIKgRIDiEyMfYVcjSE X-IronPort-AV: E=Sophos;i="4.77,735,1336341600"; d="scan'208";a="169434770" Received: from postman1.riken.jp (HELO postman.riken.jp) ([134.160.33.161]) by mail1-smtp-roc.national.inria.fr with ESMTP; 09 Aug 2012 02:53:49 +0200 Received: from postman.riken.jp (postman1.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id 1E58332C02B1 for ; Thu, 9 Aug 2012 09:53:46 +0900 (JST) Received: from [172.27.98.103] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id 97B2232A008B for ; Thu, 9 Aug 2012 09:53:45 +0900 (JST) Message-ID: <50230A19.4010804@riken.jp> Date: Thu, 09 Aug 2012 09:53:45 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <501F9855.6080709@frisch.fr> <501F9DB9.2050805@frisch.fr> <501FAB4A.107@frisch.fr> <5022A9FE.4050006@frisch.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.9.3915 Subject: Re: [Caml-list] Compiler bug? On 08/09/2012 03:22 AM, Jesper Louis Andersen wrote: > On Wed, Aug 8, 2012 at 8:03 PM, Alain Frisch 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). > > Also, the GC itself will not be using Floating Point code at all, Is it possible to enforce that no Floating Point code is used in some part of a project (let's say a module or a library)? I have no use for it, I'm just curious. > so > we can save a lot by not saving/restoring these values on the stack. > It is akin to what the Linux kernel does: trap on the first FP > instruction and only then do work to save/restore the FP context - but > here we know a priori we never will access FP. By doing so we can cut > the time to the GC call down - and reap the benefits by having a > faster GC cycle. >