Add fallback search for extra-underscore-suffixed symbols #137
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
We'll need this version of LBT backported to 1.11 and 1.10. cc @KristofferC |
|
This isn't in Kristoffer's court yet; I need to finish this LBT release, push it through Yggdrasil, open a PR to Julia master, then tag it for backporting. :) |
|
Yes, perhaps tagging him was premature - but it would be nice to get this into 1.11 and hence the heads up. |
MKL v2024 has ILP64-suffixed symbols, but the suffix applied to FORTRAN symbols (`64`, mapping `dgemm_` to `dgemm_64`) is different from the suffix applied to non-FORTRAN symbols (`_64`, mapping `cblas_dgemm` to `cblas_dgemm_64`). This wreaks havoc with LBT, which assumes that all symbols undergo the same name transformation. To work around this, we add a fallback path to our symbol forwarding routine; if a symbol does not exist in a library, we look for the same symbol but with an underscore in front of the symbol name. Because this all happens only after we have already found `isamax_` and `dpotrf_` in `autodetect_symbol_suffix()`, we have some measure of assurance that we will not be blindly guessing ridiculous symbol names.
staticfloat
force-pushed
the
sf/mkl_v2024_fix
branch
from
2d9da74
to
53735ae
Compare
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
MKL v2024 has ILP64-suffixed symbols, but the suffix applied to FORTRAN symbols (
64, mappingdgemm_todgemm_64) is different from the suffix applied to non-FORTRAN symbols (_64, mappingcblas_dgemmtocblas_dgemm_64). This wreaks havoc with LBT, which assumes that all symbols undergo the same name transformation. To work around this, we add a fallback path to our symbol forwarding routine; if a symbol does not exist in a library, we look for the same symbol but with an underscore in front of the symbol name. Because this all happens only after we have already foundisamax_anddpotrf_inautodetect_symbol_suffix(), we have some measure of assurance that we will not be blindly guessing ridiculous symbol names.