libmvec, non-finites and fast-math

libmvec, non-finites and fast-math

[Julian Taylor]

hi,

with commit 533f9bebf969060e64c66681e275c03d6e49fcc9 the vector math 
functions were changed to call the _finite versions of the scalar 
operations.
While it makes sense in that it equalizes the results for scalar and 
vectorized math for full programs compiled with -ffast-math it hurts 
applications that only want to use that flag in part of their code.
-ffast-math implies a lot optimizations you do in general not want, in 
particular the -ffinite-math flag.

I was using libmvec in a library providing numerical operations to 
applications. To do this and not get bad ffast-math flag infecting the 
whole library I put the relevant math operations on larger data blocks 
into a single file compiled with ffast-math. As the implementation in 
libmvec respects non-finite input this worked out fine. In particular 
power(nan, 0) kept returning 1 as the scalar variant in files without 
-ffast-math.

With this new commit this is broken. The vector variant will return 
different results than the scalar code.
To get around this I now need to check for non-finites manually in my 
fast-math file. But of course compiler now gets in the way as it 
optimizes away the non-finite checks.

It seems the only option I have left is now calling the _ZGV functions 
directly and doing my own vectorized non-finite checks and blend over 
the results. This option is quite appealing as it also removes the GCC 
dependency of the functionality but I am not sure if these functions are 
really to be used by applications/libraries.

So now how to solve this problem. My suggestion would be to relax the 
requirements for vectorizing the math functions to 
-funsafe-math-optimizations instead of -ffast-math, at least when glibc 
or svml are the backends.
Then glibc should to provide _ZGV*_finite variants like it does for the 
scalar functions. That way when the whole program is compiled with 
-ffast-math you get consistent results as all calls will got to the 
_finite variants and when this is not the case all calls go to the 
regular ones.
Thoughts?

cheers,
Julian Taylor

Re: libmvec, non-finites and fast-math

[Joseph Myers]

On Tue, 2 Aug 2016, Julian Taylor wrote:

> So now how to solve this problem. My suggestion would be to relax the
> requirements for vectorizing the math functions to -funsafe-math-optimizations
> instead of -ffast-math, at least when glibc or svml are the backends.

There is currently no GCC predefined macro for 
-funsafe-math-optimizations, so such a condition is not possible with 
current GCC.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libmvec, non-finites and fast-math

[Julian Taylor]

On 02.08.2016 17:52, Joseph Myers wrote:
> On Tue, 2 Aug 2016, Julian Taylor wrote:
> 
>> So now how to solve this problem. My suggestion would be to relax the
>> requirements for vectorizing the math functions to -funsafe-math-optimizations
>> instead of -ffast-math, at least when glibc or svml are the backends.
> 
> There is currently no GCC predefined macro for 
> -funsafe-math-optimizations, so such a condition is not possible with 
> current GCC.
> 

It is GCC that decides to use the vectorized function in the first place
so that should not be a problem. Or am I misunderstanding how these
functions get called?

Re: libmvec, non-finites and fast-math

[Joseph Myers]

On Tue, 2 Aug 2016, Julian Taylor wrote:

> On 02.08.2016 17:52, Joseph Myers wrote:
> > On Tue, 2 Aug 2016, Julian Taylor wrote:
> > 
> >> So now how to solve this problem. My suggestion would be to relax the
> >> requirements for vectorizing the math functions to -funsafe-math-optimizations
> >> instead of -ffast-math, at least when glibc or svml are the backends.
> > 
> > There is currently no GCC predefined macro for 
> > -funsafe-math-optimizations, so such a condition is not possible with 
> > current GCC.
> > 
> 
> It is GCC that decides to use the vectorized function in the first place
> so that should not be a problem. Or am I misunderstanding how these
> functions get called?

See the __FAST_MATH__ conditional in sysdeps/x86/fpu/bits/math-vector.h.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: libmvec, non-finites and fast-math

[Julian Taylor]

On 02.08.2016 19:14, Joseph Myers wrote:
> On Tue, 2 Aug 2016, Julian Taylor wrote:
> 
>> On 02.08.2016 17:52, Joseph Myers wrote:
>>> On Tue, 2 Aug 2016, Julian Taylor wrote:
>>>
>>>> So now how to solve this problem. My suggestion would be to relax the
>>>> requirements for vectorizing the math functions to -funsafe-math-optimizations
>>>> instead of -ffast-math, at least when glibc or svml are the backends.
>>>
>>> There is currently no GCC predefined macro for 
>>> -funsafe-math-optimizations, so such a condition is not possible with 
>>> current GCC.
>>>
>>
>> It is GCC that decides to use the vectorized function in the first place
>> so that should not be a problem. Or am I misunderstanding how these
>> functions get called?
> 
> See the __FAST_MATH__ conditional in sysdeps/x86/fpu/bits/math-vector.h.
> 

ah its not declared simd when the flag is not set, makes sense.
Here finer grained control would be very nice, I guess I'll bring that
up in the GCC bugzilla (if it has not already been).

But the finite issue still needs resolving in glibc itself. I can
possibly try creating a patch if you think my proposal can work.