[PATCH] Trapping math and libfuncs improvements

[Eli Friedman]

On Fri, Sep 6, 2013 at 8:27 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> Ben, Chad, et al.,
>
> The attached patch cleans up the LIBBUILTIN libm function definitions, and
> improves the way in which -ftrapping-math is handled in a complementary
> way. Specifically, this patch:
>
>  1. The libm LIBBUILTIN definitions are synchronized with the __builtin_*
> definitions for libm functions. We currently have __builtin_* definitions
> for many more functions than those for which we have LIBBUILTIN
> definitions. This unnecessarily pessimizes code generation around many of
> the remaining libm functions.
>
>  2. Many of these functions can be marked as readnone so long as we can
> neglect floating point exceptions. I've added a new specifier 'T', which
> like 'e' for errno, marks the builtin as const so long as trapping math is
> disabled. I've added a TrappingMath lang option to track this.
>
>  3. Disables -ftrapping-math by default. This is currently enabled by
> default (following gcc), but this is silly. No system of which I'm aware
> actually traps on floating-point exceptions by default (some
> system-specific mechanism is necessary in order to enable SIGFPE
> generation). In addition, in Clang, we currently don't support fenv access.
> As a result, we can turn this off by default (and enable better code
> generation around the functions for which we have LIBBUILTIN definitions).
>
>  4. Updates the CodeGen/libcall-declarations.c test case.
>
> As a side effect, the existing libm LIBBUILTIN definitions that were
> missing the 'n' (nothrow) specifier now have it.
>

For clarity, please split the patch into four separate patches:
reformatting, adding missing 'n' specifiers, the trapping-math-related
changes, and adding new LIBBUILTIN definitions (preferably in that order).
 As it is, the Builtins.def changes are completely unreviewable.

Your changes could be substantially simplified if we don't allow enabling
-ftrapping-math; as you've noted, we don't honor it anyway.  What do you
think?

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130906/481b4ea4/attachment.html>