On Thu, Jun 28, 2018 at 10:34:35AM -0700, Steve Kargl wrote:
> On Thu, Jun 28, 2018 at 07:03:05PM +0200, Jakub Jelinek wrote:
> > > In fact, I'll be submitting a bug report for a missed optimization.
> > >
> > > subroutine foo(x,y) subroutine foo(x,y)
> > > real x(10), y(10) real x(10), y(10)
> > > y = 0*sin(x) y = 0
> > > end subroutine foo end subroutine foo
> > >
> > > .L2: pxor %xmm0, %xmm0
> > > call sinf movq $0, 32(%rsi)
> > > pxor %xmm1, %xmm1 movups %xmm0, (%rsi)
> > > mulss %xmm1, %xmm0 movups %xmm0, 16(%rsi)
> > > movss %xmm0, 0(%rbp,%rbx)
> > > addq $4, %rbx
> > > cmpq $40, %rbx
> > > jne .L2
> > >
> > > which I'm sure you'll just be thrilled with.
> >
> > For floating point, you generally need -ffast-math to be able to
> > optimize such computations away, sinf already has const attribute (at least
> > in C/C++), so with -ffast-math it is optimized.
>
> Doesn't -ffast-math allow the violaton of the integrity
> of parentheses? That is, it allows more optimizations
> that violate the standard.
No, -ffast-math doesn't turn on -fno-protect-parens, only -Ofast does AFAIK.
Furthermore, to optimize away the sinf, you just need a subset of
-ffast-math, in particular -O2 -ffinite-math-only -fno-signed-zeros
optimizes it to zero stores too. But without those 2 options it can't be
done, as if sinf returns e.g. negative value -1.0, then 0 * -1.0 is -0.0,
not 0.0, so optimizing it into 0.0 would be incorrect. Similarly, if
the function would return Inf or -Inf or NaN (I know sinf should never
return Inf or -Inf, but it can return NaN, e.g. sinf (__builtin_inff ())
is NaN, or sinf (__builtin_nanf ("")) too), then 0 * NaN is NaN, not 0.
Jakub
