staticfloat
commented
2 years ago @ViralBShah Once this goes green, I think we will be able to use MKL v2022. Note that I actually needed to solve two problems: the first is one we never noticed, which is that MKL likes to use a different return value calling convention than gfortran does. I believe this is because we haven't configured MKL properly (it should have the mode, at least on some platforms, to use the "normal" convention) but rather than try to autoconfigure the library, I decided to just teach LBT how to work around it for the few affected functions. This change is a little dangerous, and needs to be fully tested across all platforms (as you can see, it's not working on linux x86 yet, for instance).
The second change was to forward some of our CBLAS functions (specifically, the _sub ones) to their corresponding FORTRAN functions. This allows us to work around the MKL v2022.0 issue, where some of the CBLAS functions are missing.
ViralBShah
When using
libmkl_rt, it tends to provide the intel interface rather than the gfortran interface, which causes{c,z}dot{u,c}to expect an implicit argument to store the return value in. We provide some autodetection of this, and build some wrappers to work around this for the eight functions affected.In MKL v2022.0, special ILP64-suffixed symbols are provided for the FORTRAN symbols, but not for the CBLAS ones. While we tend to use the FORTRAN symbols for most tasks, there are a few CBLAS symbols we use in the Julia world, presumably because of the above ABI problem. Now that that is fixed, we can likely stop using the CBLAS methods completely and use only the FORTRAN symbols, but for completeness, we detect missing ILP64-suffixed versions as well and forward them to the appropriate FORTRAN symbols.
Note that a fully complete mapping of CBLAS -> FORTRAN symbols would be ideal here, however that is a large undertaking, and so we choose here to be selective in which functions we provide mappings for.