[PATCH] D77484: [Vector] Pass VectLib to LTO backend so TLI build correct vector function list

[Teresa Johnson via Phabricator via cfe-commits]

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