Web lists-archives.com

Re: RFC: Naming convention for ILP64 variant of BLAS/LAPACK

Le lundi 22 octobre 2018 à 18:38 +0100, Simon McVittie a écrit :
> On Mon, 22 Oct 2018 at 18:17:32 +0100, Ben Hutchings wrote:
> > On Mon, 2018-10-22 at 15:07 +0000, Mo Zhou wrote:
> > > Here are some references:
> > > 
> > > 1. https://software.intel.com/en-us/mkl-linux-developer-guide-using-the-ilp64-interface-vs-lp64-interface
> > > 
> > >    The Intel MKL ILP64 libraries use the 64-bit integer type (necessary
> > >    for indexing large arrays, with more than 231-1 elements), whereas
> > >    the LP64 libraries index arrays with the 32-bit integer type.
> > 
> > [...]
> > 
> > The correct C types for indexing arrays are ptrdiff_t and size_t. 
> > These are already 64-bit in LP64 ABIs.  So this seems like a workaround
> > for code using the wrong types.
> Do BLAS/LAPACK really mean ILP64, or do they really mean "ABI with large
> array indexes"?

The latter. This is why I think that "ILP64" is a misnomer, and should
not be used for labeling the newly introduced libraries.

The ambiguity arises from the fact that some BLAS/LAPACK
implementations are written in Fortran, and use the default integer
type for array indexes. Hence the solution is to compile them with
-fdefault-integer-8. But this does not mean that this code is really
ILP64, because it's not C and hence it does not uses the C ABI. Only
integers exposed through the BLAS/LAPACK ABI are affected (most of them
are array indices, the remaining others are return codes).

For BLAS/LAPACK implementations implemented in C, like OpenBLAS, they
will be compiled using LP64, and not ILP64. Only integers exposed
through the interface will be affected, through the use of appropriate


⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

Attachment: signature.asc
Description: This is a digitally signed message part