Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 Nov 2012 15:07:11 +0100
From:      Roman Divacky <rdivacky@freebsd.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Dimitry Andric <dim@FreeBSD.org>, Jung-uk Kim <jkim@FreeBSD.org>
Subject:   Re: svn commit: r242715 - head/sys/conf
Message-ID:  <20121108140711.GA7213@freebsd.org>
In-Reply-To: <20121108151338.G2278@besplex.bde.org>
References:  <201211072215.qA7MFSYX017265@svn.freebsd.org> <509AE28E.4020908@FreeBSD.org> <20121108151338.G2278@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> - clang fails to optimize division by (integer) 2 into multiplication
>    by (floating point with the correct type) 0.5 in the case of long
>    doubles on one supported arch (i386 IIRC).  Both compilers optimize
>    all other cases, including floats and doubles on all arches.  clang
>    with -ffast-math optimizes the broken case, but -ffast-math is
>    generally unsafe and not even fast; it shouldn't be necessary for
>    this, since this is one of the few floating point strength reductions
>    that is always safe.  This detail is not documented for either clang
>    or gcc.  clang doesn't even document the existence of -ffast-math in
>    its man page.
> 
>    Several uncommitted libm functions use the spelling of (integer) 2
>    to avoid ifdefs and/or different code to get the type right for 0.5.
>    The result is that the case of long doubles on i386 is pessimized.
>    clang has many other efficiency and ABI problems on i386, including
>    the next one.

This just got fixed upstream

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121105/155388.html

We will get it with the next import of llvm/clang.

Thank you! Roman



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121108140711.GA7213>