linalg: introduce 64-bit integer size BLAS/LAPACK implementation (ilp64)

[perazz]

I'm introducing 64-bit integer support throughout the BLAS/LAPACK implementation to address #881 and introduce support for the 64-bit MKL library.

With this update:

• Users will always seamlessly use either 32- or 64-bit integer sizes
• Can link against 64-bit external libraries such as MKL
• If linking against a 64-bit external library, the internal 32-bit version is provided, and vice versa

Key facts

• Introduce ilp64 integer kind
• Template all procedures in our BLAS/LAPACK implementation to support either ilp, ilp64, or both
• Extend all generic BLAS/LAPACK interfaces to both integer types
• Allow linking to external ilp64 libraries (such as MKL) via STDLIB_EXTERNAL_BLAS_I64 and STDLIB_EXTERNAL_LAPACK_I64

The code shows large differences because all interfaces are now templated. These are the key lines:

stdlib/include/common.fypp

Lines 77 to 81 in 4b5a6e6

	#! BLAS/LAPACK/Linear Algebra Integer Kinds
	#:set LINALG_INT_KINDS = ["ilp","ilp64"]
	#:set LINALG_INT_TYPES = ["integer({})".format(k) for k in LINALG_INT_KINDS]
	#:set LINALG_INT_SUFFIX = ["","_I64"]
	#:set LINALG_INT_KINDS_TYPES = list(zip(LINALG_INT_KINDS, LINALG_INT_TYPES, LINALG_INT_SUFFIX))

• ilp and ilp64 are now the two supported integer kinds
• 64-bit subroutine names start with stdlib_I64_*, while 32-bit versions are still stdlib_*

If we support this implementation, next I will start templating the high-level APIs.
cc: @jvdp1 @jalvesz @loiseaujc

[awvwgk]

If linking against a 64-bit external library, the internal 32-bit version is provided, and vice versa

Not sure whether I got this point correctly. If we link against the ilp64 version the stdlib built-in blas version is provided or automatically converted from ilp to ilp64? Either choice might bring surprises to the user in the former case performance depends on the choice of integer kind and in the other case conversation might require additional memory.

[perazz]

If we link against the ilp64 version the stdlib built-in blas version is provided or automatically converted from ilp to ilp64?

The idea is that 64-bit support should be there regardless whether that comes from an external implementation: in addition of, not replacing, the 32-bit version. My preference as a user, is that I would like to write codes that always work with stdlib, and not worry that some build options turned this or that off, breaking my builds.

Then, I believe it is not possible to have both 32/64 external libraries, due to name conflict (e.g. two external subroutines with different interfaces but both named dgemm ), so, the non-external version must be provided by the internal implementation.

Also, a good idea would be to provide a support routine the user can query to check if an external implementation is being used.

[jalvesz]

LGTM @perazz! would it be possible to add a comment in the README regarding the use of the macro in order to parametrize the build process?

[perazz]

@jalvesz and all: the build script allows choosing what versions to include which is great. For the pre-processed fpm versions, What do you think about creating a new stdlib-fpm-ilp64 branch that includes both 32- and 64-bit versions by default?

[perazz]

• added parameter flags in stdlib_linalg_constants the user can check whether an external library is being used
• linear algebra options documented in README
• stdlib-fpm-ilp64 branch added, receives deployment of the ilp64-enabled version. (thanks @jalvesz, was very easy to adapt the deployment script)

PS: I believe the actual deployment with commit to the fpm branches is only triggered after the PR is merged