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