Update gensymbol

[amontoison]

Fix a symbol in lapackobjs2d.

[martin-frbg]

sorry, but no. dlag2d simply does not exist. (not in Reference-LAPACK either)

[amontoison]

Should we just remove the symbols from lapackobjs2d because it is already in lapackobjs2s?

[martin-frbg]

I think it should stay exactly as it is now. What are you trying to fix here ?

[amontoison]

I was trying to add some LAPACK symbols for quadruple precision in LBT, and our script to generate the symbols in our library depends on this script.
When I copy-pasted this block of symbols (lapackobjs2d), I found that this one was the only one starting with s*, so I thought it was a typo.

[martin-frbg]

I see, thanks - certainly an oddity in the Reference LAPACK but not a typo. (Note also that neither the Reference implementation nor OpenBLAS currently supports quadruple precision, though OpenBLAS has some stubs from the early days of GotoBLAS that could mislead one into thinking they are implemented. But you probably know that)

[amontoison]

Reference-LAPACK can be easily compiled in quadruple precision with gfortran and some compiler-dependent flags, but the issue is that we don't have a standard prefix for real and complex routines in quadruple precision.

The idea was to keep the s*, d*, c*, and z* symbols untouched and still be able to link our library with a quadruple-precision BLAS/LAPACK backend.

A Makefile can be found in Reference-LAPACK:
https://github.com/Reference-LAPACK/lapack/blob/9128e2051a922c3889e3c1fccaf4ce0d230b2785/INSTALL/make.inc.gfortran-quad#L4

With LBT, we could still use the OpenBLAS library for the usual symbols and our local quadruple library for the other ones.

[martin-frbg]

oh right - however I'm not even sure if that was ever seriously tested. (On the OpenBLAS side I guess it would be possible to hook up some half-baked support using the "generic" C kernels - this would probably provide some performance improvement relative to the Reference BLAS already. Not sure I'd want to open another can of worms while I'm already struggling to keep the number of open issues at or near 100 though)

[martin-frbg]

Had another look at this - there appear to be two mutually exclusive (non-)implementations inherited from GotoBLAS, QUAD_PRECISION defines a struct of two "unsigned long" types to hold the quadruple-precision arguments but is otherwise completely unimplemented in the actual code, EXPRECISION adds -m128-bit-long-double to the CFLAGS and FFLAGS and matching corrections in some assembly kernels predominantly for Itanium

[amontoison]

Will it require a lot of work to simply compile the "generic" C kernels in quadruple precision and use the q* / x* symbols?

It could be great for prototyping and testing.
We don’t ask that it's officially supported by OpenBLAS.

[martin-frbg]

I'm trying to find out - at least the barely implemented GEMM3M kernels are acting up, and apparently this made xianyi disable what little support there was sometime in 2015

[martin-frbg]

Tentative fix now available as #4976 - adding EXPRECISION=1 should provide "long double" Q and X functions alongside their usual float/double/complex counterparts when compiling with GCC for the "GENERIC" or any optimized x86_64 target.
This may also be possible with LLVM but I have not tried yet - also the resurrected functions are compile-tested only so far, which means only the GENERIC target can reasonably be expected to function correctly.
Note also that the quad-precision functionality is limited to the respective BLAS functions and does not carry over to any LAPACK in the same build. Changing that would probably require massive code duplication at build time and preprocessing to replace the appropriate Q/X prefixes into function names, similar to how the recently implemented combined int32/int64 build works in Reference-LAPACK. (I have not even ported that one into a public OpenBLAS yet)