Allow calling BLAS functions with suffix to use ILP64 BLAS

[nalimilan]

Some programs like Julia and Numpy have started to (or tried to) use ILP64 BLAS in order to get rid of size limitations on arrays. But this creates conflicts with libraries that expect a LP64 BLAS when they are loaded in the same process (see JuliaLang/julia#4923, numpy/numpy#5906 and linked issues). The solution that has been found is to export a different BLAS API, by adding a suffix to all functions and to the library name. OpenBLAS now supports a build flag for that (OpenMathLib/OpenBLAS#459), which is used in Fedora to ship an ILP64 package.

The most common suffix is 64_, as it's already used by several programs (OpenMathLib/OpenBLAS#646). SuiteSparse offers the -DSUN64 build flag to use the suffixed API.

Would you consider supporting a similar API? It appears to be possible with the current build system. Julia uses the following Makefile instructions: https://github.com/JuliaLang/julia/blob/69fb335efe6975c52f8b3d1c66d4008ce2d0b1cb/deps/Makefile#L1316-L1332

It would be great if these could be included upstream so that a single flag needs to be switched. That would make it easier for packagers to ship both the LP64 and ILP64 versions (https://bugzilla.redhat.com/show_bug.cgi?id=1294201).

[sylvestre]

Sure. Happy to simplify your life and this sounds an interesting change.

Could you propose a pull request implementing this change?
Thanks

[nalimilan]

Cool. I'll see what I can propose. But I have no idea how to do this in CMake too. Is that a problem?

[sylvestre]

Well, the sad thing is that we have both autotools and cmake for now :) I would like to kill autotools at some points.
Anyway, I don't think it is hard to do in CMake.

[nalimilan]

I've made a PR with changes to the autotools code. Please tell me how you feel about it, and if it's OK I'll have a look at how to do this with CMake.

FWIW, a typical configure call would look like this on Fedora:

./configure LIBSUFFIX=64_ SYMBOLSUFFIX=_64 INTERFACE64=1 \
--with-blas=openblasp64_ --with-lapack=openblasp64_

Something I'm unsure about is the interaction with name mangling. I'm not sure whether the suffix should be 64_ (as in the openblas library name) or _64 (as in the function names). Only the latter looks like it would work. CC: @stevengj

[stevengj]

_64 is right. OpenBLAS refers to it as 64_, but that is because it is already appending an underscore. e.g. the dgemm function in C is written as dgemm_ (because almost all Fortran compilers these days implicitly add an underscore). So, when you append 64_ it becomes dgemm_64_, but Fortran would view this as dgemm_64, i.e. a _64 suffix.

[nalimilan]

almost all Fortran compilers these days implicitly add an underscore

This is actually the assumption I wasn't sure we could rely on. But if you say that's OK...

[stevengj]

Yes, it's true; the other conventions have mostly died out. (A holdout was Digital Visual Fortran, which used all caps without an underscore if I recall correctly, but that compiler is at the end of its rope). In any case, for Fortran compilers that don't add an underscore, OpenBLAS would have to change its mangling scheme.

[tkelman]

Implemented by #32?

ifort on Windows follows that Digital Fortran convention of no trailing underscore (and all caps I think). Recent versions might now allow specifying mangling options, like the unix versions of ifort have allowed you to do for some time, in recognition of the fact that the open-source world uses gfortran (and has no other realistic open-source option for f90+).

[nalimilan]

Implemented by #32?

Yes.