Re: why not consfold sin(const)

[Robert Dewar <dewar at gnat dot com>]

Luchezar Belev wrote:
> Hi all,
>
> when compiling with -ffast-math, gcc replaces sin(0) with 0, but does not const fold sin of any
> other const.

First, I can never remember what incorrect transformations people tolerate
with -ffast-math, but in normal circumstances, one would demand that the
result be indentical to what would have been obtained at run-time, something
that is for example impossible in general with cross-compilers (I mean
impossible, not difficult, since the algorithms for some of the built in
elementary functions have not been revealed).

Second, surely in any reasonably written program you would expect such
constants to only be defined once, so I wonder how useful this would
be in practice.

> Is there some problem with that in principle (like that would not be correct code in some
> circumstances)

If you tolerate any transformation of the kind

(mathematical expression) => (precise result of mathematical expression)
                             converted to nearest machine number.

which to me seems a reasonable rule in -ffast-math, then this is a
legitimate transformation.

> or it's just not implemented?

so in that case, yes, it's just not implemented. Note that to do this
properly you need super accurate elementary functions that are platform
independent available. That's definitely possible.

> This is also true for other builtin math funcs like log() (gcc only optimizes log(1) to 0),

Seems a rather silly optimization to me, hard to believe
that it ever arises. But harmless ...

> but it is not the case with sqrt() - in that case the compiler always constfolds and eliminates
> the
> expensive and redundant sqrt operation.

Seems reassonable, I can imagine people writing sqrt(2.0) in open
code (though there again, giving this a name and defining it as
a constant seems better style to me).