tejohnson added a comment. In D77484#1962667 <https://reviews.llvm.org/D77484#1962667>, @wenlei wrote:
> > 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. Ok then it does sound like these could be handled on a per-function basis, similar to how -fno-builtin* are handled. I.e. a function attribute to indicate the veclib, which would then be naturally preserved during LTO even after merging/importing across modules. Similar to how -fno-builtin* are handled, these would need to be examined when inlining (see the new TargetLibraryInfo::areInlineCompatible). Presumably we would want to block inlining between functions with different veclib attributes in the LTO backends. > > >> 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
