From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-172958-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 27034 invoked by alias); 14 Mar 2012 20:52:07 -0000
Received: (qmail 27016 invoked by uid 22791); 14 Mar 2012 20:52:05 -0000
X-SWARE-Spam-Status: No, hits=-7.1 required=5.0	tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from mail4-relais-sop.national.inria.fr (HELO mail4-relais-sop.national.inria.fr) (192.134.164.105)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Mar 2012 20:51:50 +0000
Received: from ip-253.net-81-220-141.rev.numericable.fr (HELO laptop-mg.local) ([81.220.141.253])  by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Mar 2012 21:51:48 +0100
Date: Wed, 14 Mar 2012 20:52:00 -0000
From: Marc Glisse <marc.glisse@inria.fr>
Reply-To: gcc@gcc.gnu.org
To: "Joseph S. Myers" <joseph@codesourcery.com>
cc: Jeff Law <law@redhat.com>, libc-alpha@sourceware.org, gcc@gcc.gnu.org,     Geert Bosch <bosch@adacore.com>,     Christoph Lauter <christoph.lauter@lip6.fr>
Subject: Re: The state of glibc libm
In-Reply-To: <Pine.LNX.4.64.1203141627170.22094@digraph.polyomino.org.uk>
Message-ID: <alpine.DEB.2.02.1203142143250.2552@laptop-mg.saclay.inria.fr>
References: <Pine.LNX.4.64.1202291655580.7156@digraph.polyomino.org.uk> <20120314143045.GG3804@xvii.vinc17.org> <4F60B64D.1020606@redhat.com> <Pine.LNX.4.64.1203141627170.22094@digraph.polyomino.org.uk>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2012-03/txt/msg00214.txt.bz2

On Wed, 14 Mar 2012, Joseph S. Myers wrote:

> I'd say that "better performance with the potential loss of accuracy"
> should be covered by -ffast-math - that GCC should generate direct use of
> fsin/fcos instructions for sin/cos for -O2 -funsafe-math-optimizations on
> x86_64, as it does on x86, unless there is some reason to think they would
> perform worse than the out-of-line implementation.

Last time I did some timings (maybe 4 years ago), for double, fsin was 
slower than the libm software implementation compiled for x87, which was 
itself slower than the same implementation compiled for sse. And the 
software implementation was more precise than fsin. My conclusion was to 
ignore fsin from then on.

-- 
Marc Glisse