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

Reply via email to