tejohnson added a comment. In D77484#1962581 <https://reviews.llvm.org/D77484#1962581>, @hoyFB wrote:
> In D77484#1962445 <https://reviews.llvm.org/D77484#1962445>, @tejohnson wrote: > > > We're trying to move towards encoding all of this in the IR. And in fact, I > > recently implemented a series of patches to make the TLI to be built > > per-function, and along with some patches from @gchatelet to encode > > -fno-builtin* as function attributes, we now handle that part of the TLII > > with IR. See D67923 <https://reviews.llvm.org/D67923> which is the last > > patch in the series. We should encode the vectlib as function attributes > > similarly, and just thread that through to the TLI. > > > That's an interesting idea. How does the linkage work if two functions have > different vectlib attributes? Linking against two vectlibs may cause name > conflicts or other issues. Actually this may be best encoded in a module metadata that with an error merging type, so that conflicting options get flagged. What happens today in a non-LTO build if conflicting veclib options are provided to different TUs? 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