wenlei added a comment. > Linking against two vectlibs may cause name conflicts or other issues.
Of all three supported match libraries, all functions from Accelerate are prefixed with `v`; all MASS library functions are suffixed with `_massv`; and all SVML functions are prefixed with `__svml_`. See `VecFuncs.def`. So at least the exported functions don't have name conflicts. > What happens today in a non-LTO build if conflicting veclib options are > provided to different TUs? I think it will work, as long as used math libraries are all provided to linker. Even if not, I'm not sure if this is something we want to actively prevent from the use of fvectlib switch. fvectlib controls codegen/optimizer, and whether the resulting codegen can leads to linking problem (if any), is kind of orthogonal, and probably no different from a regular linking/symbol resolution problem if there're conflicts in the libraries provide. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77484/new/ https://reviews.llvm.org/D77484 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
