LAPACK: building against deficient BLAS?

[mohawk2]

As part of #1419, I just tried building LAPACK with the system BLAS (Apple Accelerate). It doesn't support _gemmtr, which I believe was introduced in LAPACK with 09cb849 for various functions including _lasyf.

Is there a policy position that LAPACK takes on this? Does it simply declare that its BLAS must conform? Does it want to provide fallbacks for missing BLAS functions?

[ilayn]

It is a versioning issue. Accelerate is stuck at version 3.9.1 and whatever BLAS was at the time. But BLAS does not have its own version number. So compatibility checks are difficult.

[mohawk2]

@ilayn Quite recently, Accelerate has available 3.12 compatibility for its LAPACK (using, in C land, a #define to enable). https://developer.apple.com/documentation/accelerate/sparse_matrix_property?language=objc

But I think you're 100% right that BLAS looks like it needs independent version numbering. We could retroactively call each reference BLAS that was released with LAPACK to have that LAPACK's version, and then start being explicit going forward?

[ACSimon33]

From #1419:

This also raises the issue I brought up in #1420; master LAPACK won't currently build against BLAS without dgemmtr, which includes Apple Accelerate. That's new in 3.12.1 (and Apple's NEW_LAPACK stuff takes them to 3.12.0). What should be done about that?

I don't think this is really on us to fix. If the vendors want the newest LAPACK, they should implement the required reference BLAS routines. What we could do is add an option to automatically take the missing vendor BLAS symbols and put the corresponding reference BLAS symbols into the LAPACK library.

But I think you're 100% right that BLAS looks like it needs independent version numbering. We could retroactively call each reference BLAS that was released with LAPACK to have that LAPACK's version, and then start being explicit going forward?

I think the version number should be the same as the LAPACK version number, but there should be an ILAVER routine in the BLAS library (e.g. IBLAVER).

[martin-frbg]

I guess nobody expected the Reference BLAS to grow new routines by adopting vendor extensions, after decades of new functionality only being added as "BLAS-like functions" to LAPACK. As far as I am aware, this caused some disruptions for the R developers last year https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2025/03/07