Vector math library on FreeBSD

On Linux, vectorized implementations of intrinsic math functions (trig, exponential, etc) are available for use with gfortran via libmvec. Is there any equivalent library on FreeBSD? I see that the FreeBSD package opensolaris-libm has a library called libmvec, but I haven’t been able to get gfortran to use it and I have no idea if it’s compatible.

Do you have a toy (ie small program) that you think should make use a function from libmvec? If I look at the gcc manual and you’re using x86_64, then I see

-mveclibabi=TYPE'
 Specifies the ABI type to use for vectorizing intrinsics using an
  external library.  Supported values for TYPE are 'svml' for the
 Intel short vector math library and 'acml' for the AMD math core
 library.  To use this option, both '-ftree-vectorize' and
 '-funsafe-math-optimizations' have to be enabled, and an SVML or
 ACML ABI-compatible library must be specified at link time.

Whether the solaris library is compatible with Intel or AMD, I do not know.

Thanks for pointing that flag out! Looking into it a bit further, I think an ABI mismatch is the issue.

I tried the following toy program:

module vectest
    implicit none
contains
subroutine sub(r)
    real, intent(inout) :: r(2621440)
    r = sin(r)
end subroutine
end module

program main
    use vectest
    implicit none
    real :: r(2621440)
    call random_number(r)
    call sub(r)
    print *, r
end program

I actually had the module and program in separate files, but I compiled the module with -Ofast -march=znver2 -c -mveclibabi=svml and it did try to make svml calls (as can be seen from the disassembly). But when I tried to link, via -L/usr/local/lib/opensolaris -lmvec, I get undefined reference to vmlsSin4, and indeed, nm indicates that no such symbol exists in the opensolaris libmvec. Same issue (different function name) for the acml abi.

So I suppose that’s the answer - the FreeBSD package for gfortran hasn’t done anything special to disable vector math libraries, but no compatible vector math library exists on FreeBSD. I wonder if it would be possible to transplant a vector math library with the correct ABI over from linux… In principle the machine code is compatible (though I don’t know about the object file format), and I doubt these math functions are calling into libc or doing anything like that which would expose other platform compatibility issues.

Thanks for the code. I’ve been a long time contributor to gfortran for the simple reason that I’ve used FreeBSD since it was called 386BSD+patchkit (circa 1992). NAG had a short lived Fortran 90 compiler for FreeBSD and there was g95. In the end, I started fixing and implementing features for gfortran because I needed a modern Fortran compiler for FreeBSD.

Now, the fun fact. I also contribute code to FreeBSD for libm. I wrote or helped write many of the long double C99 functions in FreeBSD libm, and fixed a few bugs in other functions along the way (see for example git: 292815eac623 - main - Fix powf(). :slightly_smiling_face: ). And, since I’m tooting my horn, FreeBSD libm was the initial foundation for Openlibm and much of the code I submitted for FreeBSD libm has migrated to OpenBSD, NetBSD, and in a few cases glibc.

So, now, let’s see what we can do with vector math. May be we can re-use the Linux libraries for AMD acml or Intel library. Time to ping freebsd-toolchain list.

3 Likes

The cavalry has arrived! I was actually hoping you would respond to this thread, as I’ve seen your name elsewhere in conjunction with gfortran on FreeBSD… Anyways, if you are interested in looking into this a bit, I’m here to help. You’re much more familiar with both FreeBSD and gfortran than I am (though I’ve contributed a few small bug fixes to the latter), so I’m happy to take directions if you have a better idea regarding where to direct effort than I.

I noticed after posting my previous message that the actual symbol names that get chosen under -mveclibabi=svml/acml are out of date. The latest version of SVML, as it ships with the new OneAPI compilers, contains different function names from what gfortran is looking for. Same deal with ACML (which has actually been retired by AMD and folded into their AOCC compiler - with new function names). The only vectorized implementation that seems to actually work at all is under Linux, with nuclear-strength optimization flags, but no reference to -mveclibabi. It seems to be calling _ZGVdN8v_sinf, which is found within libmvec.so on Linux.

Unless directed otherwise, I’m going to see if I can figure out what part of gcc or ld is choosing those functions. We’ll have to make sure we can replicate it on FreeBSD, even if we’re able to port or transplant the actual library over.