[TLI] Per-function fveclib for math library used for vectorization

[wenlei]

Summary

Encode -fveclib setting as per-function attribute so it can be threaded through to LTO backends. Accordingly, per-function TLI now reads the attribute and populated available vector function list based on that. Note that we expect functions within the same module to share fveclib setting, so vector function list is still shared between functions, as part of the shared TargetLibraryInfoImpl. Inlining between functions with different vect lib attribute is now blocked.

[wenlei]

update

[wenlei]

rebase

[tejohnson]

Needs testing of the inline handling, and of LTO linking IR with different attributes (which is going to hit your assert, see below).

clang/lib/CodeGen/CGCall.cpp

1987

Nit: why not "vec-lib" or just "veclib", to match the option?

llvm/include/llvm/Analysis/TargetLibraryInfo.h

47

Key comment about handling of TLII vs TLI. The former is computed once per module by the analysis (which is going to be the combined module in the case of LTO), the latter is the per-function data structure.

88

To avoid building and storing the VectorDescs and ScalarDescs for every function in the TLI, what I would do is keep 3 sets of VectorDescs/ScalarDescs on the TLII object (one set per possible veclib, built once per module during construction of the TLII), then move the new VectorLibrary member to the TLI and set it there per function based on the attribute, and use it to select which pair of VectorDescs/ScalarDescs is queried.

284–285

I don't think this will do anything currently since the TLII is built once per module by the analysis. You'll hit your assert about incompatibility below first, see comment there.

llvm/lib/Analysis/TargetLibraryInfo.cpp

1544

You'll certainly hit this assert if you try LTO linking two .ll files built with different -fveclib options, because the TLII is built once per module by the analysis.

1657

This is going to override the baseline TLI veclib with whatever is the latest function we build a TLI for (and you'll hit the assert as noted earlier if they conflict).

[wenlei]

Thanks for taking a look and the suggestions, @tejohnson. Yeah, you're right about the potential conflict of attributes. Initially I thought even though we now allow this to be per-function, but since it comes from per-module switch, module level consistency can still be expected which can simplify things a bit (hence the assertion). But I overlooked the combined module from LTO.

I will get back to this later in the week - the change will be a bit more involving as there're a few other places where we populate the module level function list directly for TLII (clang and opt).

[wenlei]

address feedback, allow functions within a module to have different vectlib setting. add test case for inline compatibility check.

[tejohnson]

Great, thanks! A few minor comments below. Looks like it needs a clang-format too.

llvm/include/llvm/Analysis/TargetLibraryInfo.h

260

Suggest moving the implementation of this constructor to the .cpp file, in which case you can just set VectLibrary directly from ClVectorLibrary there and remove the member on the Impl object.

283

This is set via a flag called "inline-caller-superset-nobuiltin". Suggest changing the name to something like "inline-caller-superset-tli" to reflect new larger scope. Also add a check with that option to your new inline test case.

llvm/lib/Analysis/TargetLibraryInfo.cpp

575–576

Why not just have "i < NumVecLibs"?

586–587

ditto

1569

Should these two be llvm_unreachable?

[wenlei]

llvm/include/llvm/Analysis/TargetLibraryInfo.h

260

There're utilities that use TargetLibraryInfo, but don't link with TargetLibraryInfo.o. And looking at TargetLibraryInfo, all of the functions are in this header, so I assumed it's intentional to keep this type self-contained in this header, as it's public API, which is why I add ClVectorLibrary to Impl to pass it back to TargetLibraryInfo. For TargetLibraryInfoImpl, it's ok to have the implementation outside of the header. I can give it a try if keeping the class implementation/definition self-contained in the header isn't important.

llvm/lib/Analysis/TargetLibraryInfo.cpp

575–576

Good catch, thanks..

[tejohnson]

llvm/include/llvm/Analysis/TargetLibraryInfo.h

260

I don't think there should be anything using TLI without linking with libAnalysis, which contains TargetLibraryInfo.o. I don't think it should be important to keep the implementation in the header, any more so than for other headers in the Analysis library.

[wenlei]

address feedback

[wenlei]

llvm/include/llvm/Analysis/TargetLibraryInfo.h

260

Ok, I moved it to .cpp, thanks!

[tejohnson]

lgtm. I think one check is missing in the test, see comment below.

llvm/test/Transforms/Inline/veclib-compat.ll

29

I think NOSUPERSET should also check that there is still a call here. You can probably replace some of the duplicated checks with COMMON in this function too.

[wenlei]

rebase, update test

[nikic]

This change causes a ~0.5% compile-time regressions: http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions This is quite a lot as these things go, so it would be great if you could double check if there's any optimization potential here. In particular I'm wondering why this affects normal builds so much, even though they (presumably?) don't use any veclib at all.

[wenlei]

In D77632#1974015, @nikic wrote:

This change causes a ~0.5% compile-time regressions: http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions This is quite a lot as these things go, so it would be great if you could double check if there's any optimization potential here. In particular I'm wondering why this affects normal builds so much, even though they (presumably?) don't use any veclib at all.

Thanks for the heads-up. This is surprising but there is a change even when veclib is not used - in order to allow each function to use different veclib without duplicating the work of populating vector function list for each function, we now always pre-populate vector function list for three supported vector libraries for each module. However 0.5% compile-time for that work given it's per-module is not expected. I suspect we may be passing/copying TLII around more than we anticipated (now we always have more stuff to copy). I will take a look. We could also turn this into a lazy initialization - only populate the needed list for module level TLII when it's first queried by a function level TLI.

[tejohnson]

In D77632#1974363, @wenlei wrote:

In D77632#1974015, @nikic wrote:

This change causes a ~0.5% compile-time regressions: http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions This is quite a lot as these things go, so it would be great if you could double check if there's any optimization potential here. In particular I'm wondering why this affects normal builds so much, even though they (presumably?) don't use any veclib at all.

Thanks for the heads-up. This is surprising but there is a change even when veclib is not used - in order to allow each function to use different veclib without duplicating the work of populating vector function list for each function, we now always pre-populate vector function list for three supported vector libraries for each module. However 0.5% compile-time for that work given it's per-module is not expected. I suspect we may be passing/copying TLII around more than we anticipated (now we always have more stuff to copy). I will take a look. We could also turn this into a lazy initialization - only populate the needed list for module level TLII when it's first queried by a function level TLI.

Hmm, yeah that is surprising, because the TLII should be built once per module per TLI analysis, which is never invalidated. We've gone from populating one set of vec libs to 3, I wouldn't have thought that was particularly expensive, so it would be good to see what is going on here and confirm we are only building this once as expected.

Looking at the compile time data at that link, interestingly the "instructions" metric increased, but not wall time or cycles or task clock - they were all neutral.

[mehdi_amini]

The existing TLI provides a very convenient way to define a VecLib without LLVM knowing about it ahead of time. This feature is important for any embedded use of LLVM as a library out-of-tree (I'll add a unit-test in-tree).
I don't think it is a big change to this patch to preserve the current ability but I wanted to check first (and in the meantime I reverted in temporarily in https://reviews.llvm.org/D77925 to avoid the feature regression).

At the moment the place where you seem to use this knowledge is with the enum VectorLibrary in the TargetLibraryInfoImpl class, and the VecLibDescs array which statically contains the known VecLib.
It seems to me that if we replace this enum with a string instead to identify the VecLib everything should still hold together and this would fit with minor changes to this path. The VecLibDescs could just be a StringMap<VectorLibraryDescriptors> in this case.

That was a third-party (in my case the XLA compiler) can still register its own "XLA" VecLib and add all the descriptors.

How does it sound?

[tejohnson]

In D77632#1975619, @mehdi_amini wrote:

The existing TLI provides a very convenient way to define a VecLib without LLVM knowing about it ahead of time. This feature is important for any embedded use of LLVM as a library out-of-tree (I'll add a unit-test in-tree).
I don't think it is a big change to this patch to preserve the current ability but I wanted to check first (and in the meantime I reverted in temporarily in https://reviews.llvm.org/D77925 to avoid the feature regression).

At the moment the place where you seem to use this knowledge is with the enum VectorLibrary in the TargetLibraryInfoImpl class, and the VecLibDescs array which statically contains the known VecLib.
It seems to me that if we replace this enum with a string instead to identify the VecLib everything should still hold together and this would fit with minor changes to this path. The VecLibDescs could just be a StringMap<VectorLibraryDescriptors> in this case.

That was a third-party (in my case the XLA compiler) can still register its own "XLA" VecLib and add all the descriptors.

How does it sound?

I think this should work. Just reiterating something we chatted about off patch yesterday, we really need a unit test that mimics the behavior utilized by the XLA compiler, for regression testing.

[mehdi_amini]

In D77632#1976126, @tejohnson wrote:

I think this should work. Just reiterating something we chatted about off patch yesterday, we really need a unit test that mimics the behavior utilized by the XLA compiler, for regression testing.

Yes I pinged some of the XLA folks to make it happen.

[wenlei]

In D77632#1975619, @mehdi_amini wrote:

The existing TLI provides a very convenient way to define a VecLib without LLVM knowing about it ahead of time. This feature is important for any embedded use of LLVM as a library out-of-tree (I'll add a unit-test in-tree).
I don't think it is a big change to this patch to preserve the current ability but I wanted to check first (and in the meantime I reverted in temporarily in https://reviews.llvm.org/D77925 to avoid the feature regression).

At the moment the place where you seem to use this knowledge is with the enum VectorLibrary in the TargetLibraryInfoImpl class, and the VecLibDescs array which statically contains the known VecLib.
It seems to me that if we replace this enum with a string instead to identify the VecLib everything should still hold together and this would fit with minor changes to this path. The VecLibDescs could just be a StringMap<VectorLibraryDescriptors> in this case.

That was a third-party (in my case the XLA compiler) can still register its own "XLA" VecLib and add all the descriptors.

How does it sound?

Thanks for the explanation about the revert. The proposal of using a StringMap to maintain the openness sounds good to me. And agree with @tejohnson, if the openness is a feature, it should be covered in tests, otherwise it can feel somewhat like a loophole and prone to breakage, though I can see how it can be useful.. Hope this patch can be restored with tweaks soon (we have workloads with very visible vectorization that relies on this).

[wenlei]

In D77632#1974409, @tejohnson wrote:

In D77632#1974363, @wenlei wrote:

In D77632#1974015, @nikic wrote:

This change causes a ~0.5% compile-time regressions: http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions This is quite a lot as these things go, so it would be great if you could double check if there's any optimization potential here. In particular I'm wondering why this affects normal builds so much, even though they (presumably?) don't use any veclib at all.

Thanks for the heads-up. This is surprising but there is a change even when veclib is not used - in order to allow each function to use different veclib without duplicating the work of populating vector function list for each function, we now always pre-populate vector function list for three supported vector libraries for each module. However 0.5% compile-time for that work given it's per-module is not expected. I suspect we may be passing/copying TLII around more than we anticipated (now we always have more stuff to copy). I will take a look. We could also turn this into a lazy initialization - only populate the needed list for module level TLII when it's first queried by a function level TLI.

Hmm, yeah that is surprising, because the TLII should be built once per module per TLI analysis, which is never invalidated. We've gone from populating one set of vec libs to 3, I wouldn't have thought that was particularly expensive, so it would be good to see what is going on here and confirm we are only building this once as expected.

Looking at the compile time data at that link, interestingly the "instructions" metric increased, but not wall time or cycles or task clock - they were all neutral.

Turns out there're a few places where we call copy ctor for TLI unnecessarily. Made some changes in D77952 to use move when possible. In addition, I should have used move for TLI.VecLibDescs in move ctor of TargetLibraryInfoImpl too.

[mehdi_amini]

In D77632#1976231, @wenlei wrote:

And agree with @tejohnson, if the openness is a feature, it should be covered in tests, otherwise it can feel somewhat like a loophole and prone to breakage

The thing is that LLVM does not have much C++ unittests in general, so most of the "features" like this one that LLVM offers as a library are just an artifact of being "designed as a library" and being mindful about the layering.
From this point of view this patch is changing the design of a component that was modular/pluggable into a closed system. I'm perfectly fine with trying to add a unit-test, I just don't know yet where it would fit in the LLVM testing though.

[tejohnson]

In D77632#1976240, @wenlei wrote:

In D77632#1974409, @tejohnson wrote:

In D77632#1974363, @wenlei wrote:

In D77632#1974015, @nikic wrote:

This change causes a ~0.5% compile-time regressions: http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88&to=60c642e74be6af86906d9f3d982728be7bd4329f&stat=instructions This is quite a lot as these things go, so it would be great if you could double check if there's any optimization potential here. In particular I'm wondering why this affects normal builds so much, even though they (presumably?) don't use any veclib at all.

Thanks for the heads-up. This is surprising but there is a change even when veclib is not used - in order to allow each function to use different veclib without duplicating the work of populating vector function list for each function, we now always pre-populate vector function list for three supported vector libraries for each module. However 0.5% compile-time for that work given it's per-module is not expected. I suspect we may be passing/copying TLII around more than we anticipated (now we always have more stuff to copy). I will take a look. We could also turn this into a lazy initialization - only populate the needed list for module level TLII when it's first queried by a function level TLI.

Hmm, yeah that is surprising, because the TLII should be built once per module per TLI analysis, which is never invalidated. We've gone from populating one set of vec libs to 3, I wouldn't have thought that was particularly expensive, so it would be good to see what is going on here and confirm we are only building this once as expected.

Looking at the compile time data at that link, interestingly the "instructions" metric increased, but not wall time or cycles or task clock - they were all neutral.

Turns out there're a few places where we call copy ctor for TLI unnecessarily.

I assume you mean the TargetLibraryInfoImpl (TLII) here, not the TargetLibraryInfo (TLI), right? The latter should be cheap to copy. Are these the changes in BackendUtil.cpp in D77952? I had a question about that on that patch as I think we will be calling the initializer more. Mostly we should only be copying the TargetLibraryInfo during optimization though, and not the TLII impl object.

Made some changes in D77952 to use move when possible. In addition, I should have used move for TLI.VecLibDescs in move ctor of TargetLibraryInfoImpl too.

[nikic]

I gave D77952 a try (on top of this one), but didn't see a significant improvement from that change.

Looking at the callgrind output for compilation of a small file, I see 52M total instructions, 4 calls to TLII initialization, where addition of the vector functions takes up the majority of the time, at 0.7M. Most of the cost is in the sorting. 2 of the initialization calls are default-constructed TLII without target triple, which seems suspect to me (are we not adding TLI early enough, and something pulls it in via analysis dependency?)

So for small files, just registering the vector functions does make up a non-trivial fraction of time, and lazy initialization might make sense. This isn't the whole truth though: While the largest regressions are indeed on small files, there are also quite a few > 1% regressions on very large files.

For a mid-size file with ~6000M instructions retried, the main difference I see is TargetLibraryAnalysis::run() going up from 82M to 126M, with the cost coming from the extra getFnAttribute("veclib") call in the TargetLibraryInfo constructor. Fetching attributes is surprisingly expensive, as it performs an iteration over all attributes internally. As this code is iterating over all attributes anyway in order to handle no-builtin-*, it might make sense to move the checks for "veclib" and "no-builtins" into that loop as well, which should make them essentially free.

[tejohnson]

In D77632#1976308, @mehdi_amini wrote:

In D77632#1976231, @wenlei wrote:

And agree with @tejohnson, if the openness is a feature, it should be covered in tests, otherwise it can feel somewhat like a loophole and prone to breakage

The thing is that LLVM does not have much C++ unittests in general, so most of the "features" like this one that LLVM offers as a library are just an artifact of being "designed as a library" and being mindful about the layering.
From this point of view this patch is changing the design of a component that was modular/pluggable into a closed system.

The interfaces being relied on were in the underlying Impl class, I think if that is expected to be pluggable and stable it really needs unit testing to reflect that usage.

I'm perfectly fine with trying to add a unit-test, I just don't know yet where it would fit in the LLVM testing though.

Presumably the testing should be in llvm/unittests/Analysis/TargetLibraryInfoTest.cpp, which already exists but only tests the LibFuncs (builtins) interfaces.

clang/lib/CodeGen/BackendUtil.cpp

static void addDataFlowSanitizerPass(const PassManagerBuilder &Builder,
   PM.add(createDataFlowSanitizerPass(LangOpts.SanitizerBlacklistFiles));
 }
 
 static void addMemTagOptimizationPasses(const PassManagerBuilder &Builder,
                                         legacy::PassManagerBase &PM) {
   PM.add(createStackSafetyGlobalInfoWrapperPass(/*SetMetadata=*/true));
 }
 
-static TargetLibraryInfoImpl *createTLII(llvm::Triple &TargetTriple,
-                                         const CodeGenOptions &CodeGenOpts) {
-  TargetLibraryInfoImpl *TLII = new TargetLibraryInfoImpl(TargetTriple);
-
-  switch (CodeGenOpts.getVecLib()) {
-  case CodeGenOptions::Accelerate:
-    TLII->addVectorizableFunctionsFromVecLib(TargetLibraryInfoImpl::Accelerate);
-    break;
-  case CodeGenOptions::MASSV:
-    TLII->addVectorizableFunctionsFromVecLib(TargetLibraryInfoImpl::MASSV);
-    break;
-  case CodeGenOptions::SVML:
-    TLII->addVectorizableFunctionsFromVecLib(TargetLibraryInfoImpl::SVML);
-    break;
-  default:
-    break;
-  }
-  return TLII;
+static TargetLibraryInfoImpl *createTLII(llvm::Triple &TargetTriple) {
+  return new TargetLibraryInfoImpl(TargetTriple);
 }
 
 static void addSymbolRewriterPass(const CodeGenOptions &Opts,
                                   legacy::PassManager *MPM) {
   llvm::SymbolRewriter::RewriteDescriptorList DL;
 
   llvm::SymbolRewriter::RewriteMapParser MapParser;
   for (const auto &MapFile : Opts.RewriteMapFiles)
void EmitAssemblyHelper::CreatePasses(legacy::PassManager &MPM,
   if (CodeGenOpts.DisableLLVMPasses)
     return;
 
   // Figure out TargetLibraryInfo.  This needs to be added to MPM and FPM
   // manually (and not via PMBuilder), since some passes (eg. InstrProfiling)
   // are inserted before PMBuilder ones - they'd get the default-constructed
   // TLI with an unknown target otherwise.
   Triple TargetTriple(TheModule->getTargetTriple());
-  std::unique_ptr<TargetLibraryInfoImpl> TLII(
-      createTLII(TargetTriple, CodeGenOpts));
+  std::unique_ptr<TargetLibraryInfoImpl> TLII(createTLII(TargetTriple));
 
   // If we reached here with a non-empty index file name, then the index file
   // was empty and we are not performing ThinLTO backend compilation (used in
   // testing in a distributed build environment). Drop any the type test
   // assume sequences inserted for whole program vtables so that codegen doesn't
   // complain.
   if (!CodeGenOpts.ThinLTOIndexFile.empty())
     MPM.add(createLowerTypeTestsPass(/*ExportSummary=*/nullptr,

 }
 
 bool EmitAssemblyHelper::AddEmitPasses(legacy::PassManager &CodeGenPasses,
                                        BackendAction Action,
                                        raw_pwrite_stream &OS,
                                        raw_pwrite_stream *DwoOS) {
   // Add LibraryInfo.
   llvm::Triple TargetTriple(TheModule->getTargetTriple());
-  std::unique_ptr<TargetLibraryInfoImpl> TLII(
-      createTLII(TargetTriple, CodeGenOpts));
+  std::unique_ptr<TargetLibraryInfoImpl> TLII(createTLII(TargetTriple));
   CodeGenPasses.add(new TargetLibraryInfoWrapperPass(*TLII));
 
   // Normal mode, emit a .s or .o file by running the code generator. Note,
   // this also adds codegenerator level optimization passes.
   CodeGenFileType CGFT = getCodeGenFileType(Action);
 
   // Add ObjC ARC final-cleanup optimizations. This is done as part of the
   // "codegen" passes so that it isn't run multiple times when there is
#include "llvm/Support/Extension.def"
   ModuleAnalysisManager MAM(CodeGenOpts.DebugPassManager);
 
   // Register the AA manager first so that our version is the one used.
   FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
 
   // Register the target library analysis directly and give it a customized
   // preset TLI.
   Triple TargetTriple(TheModule->getTargetTriple());
-  std::unique_ptr<TargetLibraryInfoImpl> TLII(
-      createTLII(TargetTriple, CodeGenOpts));
+  std::unique_ptr<TargetLibraryInfoImpl> TLII(createTLII(TargetTriple));
   FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
 
   // Register all the basic analyses with the managers.
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
   PB.registerFunctionAnalyses(FAM);
   PB.registerLoopAnalyses(LAM);
   PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);

clang/lib/CodeGen/CGCall.cpp

if (llvm::is_contained(NBA->builtinNames(), "*")) {
     FuncAttrs.addAttribute("no-builtins");
     return;
   }
 
   // And last, add the rest of the builtin names.
   llvm::for_each(NBA->builtinNames(), AddNoBuiltinAttr);
 }
 
+static void addVectLibAttributes(llvm::AttrBuilder &FuncAttrs,
+                                 const CodeGenOptions &CodeGenOpts) {
+  StringRef AttributeName = "veclib";
+  switch (CodeGenOpts.getVecLib()) {
+  case CodeGenOptions::Accelerate:
+    FuncAttrs.addAttribute(AttributeName, "Accelerate");
+    break;
+  case CodeGenOptions::MASSV:
+    FuncAttrs.addAttribute(AttributeName, "MASSV");
+    break;
+  case CodeGenOptions::SVML:
+    FuncAttrs.addAttribute(AttributeName, "SVML");
+    break;
+  case CodeGenOptions::NoLibrary:
+    break;
+  }
+}
+
 void CodeGenModule::ConstructAttributeList(
     StringRef Name, const CGFunctionInfo &FI, CGCalleeInfo CalleeInfo,
     llvm::AttributeList &AttrList, unsigned &CallingConv, bool AttrOnCallSite) {
   llvm::AttrBuilder FuncAttrs;
   llvm::AttrBuilder RetAttrs;
 
   CallingConv = FI.getEffectiveCallingConvention();
   if (FI.isNoReturn())
void CodeGenModule::ConstructAttributeList(
   // Attach "no-builtins" attributes to:
   // * call sites: both `nobuiltin` and "no-builtins" or "no-builtin-<name>".
   // * definitions: "no-builtins" or "no-builtin-<name>" only.
   // The attributes can come from:
   // * LangOpts: -ffreestanding, -fno-builtin, -fno-builtin-<name>
   // * FunctionDecl attributes: __attribute__((no_builtin(...)))
   addNoBuiltinAttributes(FuncAttrs, getLangOpts(), NBA);
 
+  // Attach "veclib" attribute to function based on '-fveclib' setting.
+  addVectLibAttributes(FuncAttrs, getCodeGenOpts());
+
   ConstructDefaultFnAttrList(Name, HasOptnone, AttrOnCallSite, FuncAttrs);
 
   // This must run after constructing the default function attribute list
   // to ensure that the speculative load hardening attribute is removed
   // in the case where the -mspeculative-load-hardening flag was passed.
   if (TargetDecl) {
     if (TargetDecl->hasAttr<NoSpeculativeLoadHardeningAttr>())
       FuncAttrs.removeAttribute(llvm::Attribute::SpeculativeLoadHardening);

clang/test/CodeGen/libcalls-veclib.c

+// RUN: %clang_cc1 -S -emit-llvm -fveclib=SVML -o - %s | FileCheck --check-prefixes=SVML %s
+// RUN: %clang_cc1 -S -emit-llvm -fveclib=Accelerate -o - %s | FileCheck --check-prefixes=ACCELERATE %s
+// RUN: %clang_cc1 -S -emit-llvm -fveclib=MASSV -o - %s | FileCheck --check-prefixes=MASSV %s
+// RUN: %clang_cc1 -S -emit-llvm -fveclib=none -o - %s | FileCheck --check-prefixes=NOLIB %s
+// RUN: %clang_cc1 -S -emit-llvm -o - %s | FileCheck --check-prefixes=NOLIB %s
+
+int main() {
+  return 0;
+}
+
+// SVML: "veclib"="SVML"
+// ACCELERATE: "veclib"="Accelerate"
+// MASSV: "veclib"="MASSV"
+// NOLIB-NOT: "veclib"
 No newline at end of file

llvm/include/llvm/Analysis/TargetLibraryInfo.h

#include "llvm/Analysis/TargetLibraryInfo.def"
     NotLibFunc
   };
 
 /// Implementation of the target library information.
 ///
 /// This class constructs tables that hold the target library information and
 /// make it available. However, it is somewhat expensive to compute and only
 /// depends on the triple. So users typically interact with the \c
 /// TargetLibraryInfo wrapper below.
 class TargetLibraryInfoImpl {
   friend class TargetLibraryInfo;
 
+public:
+  /// List of known vector-functions libraries.
+  ///
+  /// The vector-functions library defines, which functions are vectorizable
+  /// and with which factor. The library can be specified by either frontend,
+  /// or a commandline option, and then used by
+  /// addVectorizableFunctionsFromVecLib for filling up the tables of
+  /// vectorizable functions.
+  enum VectorLibrary {
+    Accelerate, // Use Accelerate framework.
+    MASSV,      // IBM MASS vector library.
+    SVML,       // Intel short vector math library.
+    NumVecLibs, // Number of supported vector libraries.
+    NoLibrary   // Don't use any vector library.
+  };
+
+private:
   unsigned char AvailableArray[(NumLibFuncs+3)/4];
   llvm::DenseMap<unsigned, std::string> CustomNames;
   static StringLiteral const StandardNames[NumLibFuncs];
   bool ShouldExtI32Param, ShouldExtI32Return, ShouldSignExtI32Param;
 
   enum AvailabilityState {
     StandardName = 3, // (memset to all ones)
     CustomName = 1,
     Unavailable = 0  // (memset to all zeros)
   };
   void setState(LibFunc F, AvailabilityState State) {
     AvailableArray[F/4] &= ~(3 << 2*(F&3));
     AvailableArray[F/4] |= State << 2*(F&3);
   }
   AvailabilityState getState(LibFunc F) const {
     return static_cast<AvailabilityState>((AvailableArray[F/4] >> 2*(F&3)) & 3);
   }
 
+  /// Vector library descriptor for all supported ones.
+  struct VectorLibraryDescriptors {
     /// Vectorization descriptors - sorted by ScalarFnName.
     std::vector<VecDesc> VectorDescs;
     /// Scalarization descriptors - same content as VectorDescs but sorted based
     /// on VectorFnName rather than ScalarFnName.
     std::vector<VecDesc> ScalarDescs;
+  } VecLibDescs[NumVecLibs];
 
   /// Return true if the function type FTy is valid for the library function
   /// F, regardless of whether the function is available.
   bool isValidProtoForLibFunc(const FunctionType &FTy, LibFunc F,
                               const DataLayout *DL) const;
 
-public:
-  /// List of known vector-functions libraries.
-  ///
-  /// The vector-functions library defines, which functions are vectorizable
-  /// and with which factor. The library can be specified by either frontend,
-  /// or a commandline option, and then used by
-  /// addVectorizableFunctionsFromVecLib for filling up the tables of
-  /// vectorizable functions.
-  enum VectorLibrary {
-    NoLibrary,  // Don't use any vector library.
-    Accelerate, // Use Accelerate framework.
-    MASSV,      // IBM MASS vector library.
-    SVML        // Intel short vector math library.
-  };
+  /// Add a set of scalar -> vector mappings, queryable via
+  /// getVectorizedFunction and getScalarizedFunction.
+  void addVectorizableFunctions(ArrayRef<VecDesc> Fns,
+                                VectorLibraryDescriptors &VetLibDescs);
 
+  /// Calls addVectorizableFunctionsFromVecLib with a known preset of functions
+  /// for the given vector library.
+  void addVectorizableFunctionsFromVecLib(enum VectorLibrary VecLib,
+                                          VectorLibraryDescriptors &VetLibDesc);
+
+public:
   TargetLibraryInfoImpl();
   explicit TargetLibraryInfoImpl(const Triple &T);
 
   // Provide value semantics.
   TargetLibraryInfoImpl(const TargetLibraryInfoImpl &TLI);
   TargetLibraryInfoImpl(TargetLibraryInfoImpl &&TLI);
   TargetLibraryInfoImpl &operator=(const TargetLibraryInfoImpl &TLI);
   TargetLibraryInfoImpl &operator=(TargetLibraryInfoImpl &&TLI);
void setAvailableWithName(LibFunc F, StringRef Name) {
     }
   }
 
   /// Disables all builtins.
   ///
   /// This can be used for options like -fno-builtin.
   void disableAllFunctions();
 
-  /// Add a set of scalar -> vector mappings, queryable via
-  /// getVectorizedFunction and getScalarizedFunction.
-  void addVectorizableFunctions(ArrayRef<VecDesc> Fns);
-
-  /// Calls addVectorizableFunctions with a known preset of functions for the
-  /// given vector library.
-  void addVectorizableFunctionsFromVecLib(enum VectorLibrary VecLib);
+  /// Populate VectorLibraryDescriptors for all supported vector libraries.
+  void addAllVectorizableFunctions();
 
   /// Return true if the function F has a vector equivalent with vectorization
   /// factor VF.
-  bool isFunctionVectorizable(StringRef F, unsigned VF) const {
-    return !getVectorizedFunction(F, VF).empty();
+  bool isFunctionVectorizable(StringRef F, unsigned VF,
+                              VectorLibrary vecLib) const {
+    return !getVectorizedFunction(F, VF, vecLib).empty();
   }
 
   /// Return true if the function F has a vector equivalent with any
   /// vectorization factor.
-  bool isFunctionVectorizable(StringRef F) const;
+  bool isFunctionVectorizable(StringRef F, VectorLibrary vecLib) const;
 
   /// Return the name of the equivalent of F, vectorized with factor VF. If no
   /// such mapping exists, return the empty string.
-  StringRef getVectorizedFunction(StringRef F, unsigned VF) const;
+  StringRef getVectorizedFunction(StringRef F, unsigned VF,
+                                  VectorLibrary vecLib) const;
 
   /// Return true if the function F has a scalar equivalent, and set VF to be
   /// the vectorization factor.
-  bool isFunctionScalarizable(StringRef F, unsigned &VF) const {
-    return !getScalarizedFunction(F, VF).empty();
+  bool isFunctionScalarizable(StringRef F, unsigned &VF,
+                              VectorLibrary vecLib) const {
+    return !getScalarizedFunction(F, VF, vecLib).empty();
   }
 
   /// Return the name of the equivalent of F, scalarized. If no such mapping
   /// exists, return the empty string.
   ///
   /// Set VF to the vectorization factor.
-  StringRef getScalarizedFunction(StringRef F, unsigned &VF) const;
+  StringRef getScalarizedFunction(StringRef F, unsigned &VF,
+                                  VectorLibrary vecLib) const;
 
   /// Set to true iff i32 parameters to library functions should have signext
   /// or zeroext attributes if they correspond to C-level int or unsigned int,
   /// respectively.
   void setShouldExtI32Param(bool Val) {
     ShouldExtI32Param = Val;
   }
 
public:
   }
 
   /// Returns the size of the wchar_t type in bytes or 0 if the size is unknown.
   /// This queries the 'wchar_size' metadata.
   unsigned getWCharSize(const Module &M) const;
 
   /// Returns the largest vectorization factor used in the list of
   /// vector functions.
-  unsigned getWidestVF(StringRef ScalarF) const;
+  unsigned getWidestVF(StringRef ScalarF, VectorLibrary vecLib) const;
 };
 
 /// Provides information about what library functions are available for
 /// the current target.
 ///
 /// This both allows optimizations to handle them specially and frontends to
 /// disable such optimizations through -fno-builtin etc.
 class TargetLibraryInfo {
   friend class TargetLibraryAnalysis;
   friend class TargetLibraryInfoWrapperPass;
 
   /// The global (module level) TLI info.
   const TargetLibraryInfoImpl *Impl;
 
+  /// Vector library available for vectorization.
+  TargetLibraryInfoImpl::VectorLibrary VectLibrary =
+      TargetLibraryInfoImpl::NoLibrary;
+
   /// Support for -fno-builtin* options as function attributes, overrides
   /// information in global TargetLibraryInfoImpl.
   BitVector OverrideAsUnavailable;
 
+  TargetLibraryInfoImpl::VectorLibrary
+  getVecLibFromName(const StringRef &VecLibName) {
+    if (VecLibName == "Accelerate")
+      return TargetLibraryInfoImpl::Accelerate;
+    else if (VecLibName == "MASSV")
+      return TargetLibraryInfoImpl::MASSV;
+    else if (VecLibName == "SVML")
+      return TargetLibraryInfoImpl::SVML;
+    return TargetLibraryInfoImpl::NoLibrary;
+  }
+
 public:
   explicit TargetLibraryInfo(const TargetLibraryInfoImpl &Impl,
-                             Optional<const Function *> F = None)
-      : Impl(&Impl), OverrideAsUnavailable(NumLibFuncs) {
-    if (!F)
-      return;
-    if ((*F)->hasFnAttribute("no-builtins"))
-      disableAllFunctions();
-    else {
-      // Disable individual libc/libm calls in TargetLibraryInfo.
-      LibFunc LF;
-      AttributeSet FnAttrs = (*F)->getAttributes().getFnAttributes();
-      for (const Attribute &Attr : FnAttrs) {
-        if (!Attr.isStringAttribute())
-          continue;
-        auto AttrStr = Attr.getKindAsString();
-        if (!AttrStr.consume_front("no-builtin-"))
-          continue;
-        if (getLibFunc(AttrStr, LF))
-          setUnavailable(LF);
-      }
-    }
-  }
+                             Optional<const Function *> F = None);
 
   // Provide value semantics.
   TargetLibraryInfo(const TargetLibraryInfo &TLI)
-      : Impl(TLI.Impl), OverrideAsUnavailable(TLI.OverrideAsUnavailable) {}
+      : Impl(TLI.Impl), VectLibrary(TLI.VectLibrary),
+        OverrideAsUnavailable(TLI.OverrideAsUnavailable) {}
   TargetLibraryInfo(TargetLibraryInfo &&TLI)
-      : Impl(TLI.Impl), OverrideAsUnavailable(TLI.OverrideAsUnavailable) {}
+      : Impl(TLI.Impl), VectLibrary(TLI.VectLibrary),
+        OverrideAsUnavailable(TLI.OverrideAsUnavailable) {}
   TargetLibraryInfo &operator=(const TargetLibraryInfo &TLI) {
     Impl = TLI.Impl;
+    VectLibrary = TLI.VectLibrary;
     OverrideAsUnavailable = TLI.OverrideAsUnavailable;
     return *this;
   }
   TargetLibraryInfo &operator=(TargetLibraryInfo &&TLI) {
     Impl = TLI.Impl;
+    VectLibrary = TLI.VectLibrary;
     OverrideAsUnavailable = TLI.OverrideAsUnavailable;
     return *this;
   }
 
   /// Determine whether a callee with the given TLI can be inlined into
-  /// caller with this TLI, based on 'nobuiltin' attributes. When requested,
-  /// allow inlining into a caller with a superset of the callee's nobuiltin
-  /// attributes, which is conservatively correct.
+  /// caller with this TLI, based on 'nobuiltin', `veclib` attributes.
+  /// When requested, allow inlining into a caller with a superset of the
+  /// callee's attributes, which is conservatively correct.
   bool areInlineCompatible(const TargetLibraryInfo &CalleeTLI,
                            bool AllowCallerSuperset) const {
     if (!AllowCallerSuperset)
-      return OverrideAsUnavailable == CalleeTLI.OverrideAsUnavailable;
+      return VectLibrary == CalleeTLI.VectLibrary &&
+             OverrideAsUnavailable == CalleeTLI.OverrideAsUnavailable;
     BitVector B = OverrideAsUnavailable;
     B |= CalleeTLI.OverrideAsUnavailable;
-    // We can inline if the union of the caller and callee's nobuiltin
-    // attributes is no stricter than the caller's nobuiltin attributes.
-    return B == OverrideAsUnavailable;
+    // We can inline if the union of the caller and callee's attributes
+    // is no stricter than the caller's attributes.
+    bool VecLibCompatible =
+        (VectLibrary == CalleeTLI.VectLibrary) ||
+        CalleeTLI.VectLibrary == TargetLibraryInfoImpl::NoLibrary;
+    return B == OverrideAsUnavailable && VecLibCompatible;
   }
 
   /// Searches for a particular function name.
   ///
   /// If it is one of the known library functions, return true and set F to the
   /// corresponding value.
   bool getLibFunc(StringRef funcName, LibFunc &F) const {
     return Impl->getLibFunc(funcName, F);
TargetLibraryInfoImpl::AvailabilityState getState(LibFunc F) const {
     return Impl->getState(F);
   }
 
   /// Tests whether a library function is available.
   bool has(LibFunc F) const {
     return getState(F) != TargetLibraryInfoImpl::Unavailable;
   }
   bool isFunctionVectorizable(StringRef F, unsigned VF) const {
-    return Impl->isFunctionVectorizable(F, VF);
+    return Impl->isFunctionVectorizable(F, VF, VectLibrary);
   }
   bool isFunctionVectorizable(StringRef F) const {
-    return Impl->isFunctionVectorizable(F);
+    return Impl->isFunctionVectorizable(F, VectLibrary);
   }
   StringRef getVectorizedFunction(StringRef F, unsigned VF) const {
-    return Impl->getVectorizedFunction(F, VF);
+    return Impl->getVectorizedFunction(F, VF, VectLibrary);
   }
 
   /// Tests if the function is both available and a candidate for optimized code
   /// generation.
   bool hasOptimizedCodeGen(LibFunc F) const {
     if (getState(F) == TargetLibraryInfoImpl::Unavailable)
       return false;
     switch (F) {
public:
   }
   bool invalidate(Function &, const PreservedAnalyses &,
                   FunctionAnalysisManager::Invalidator &) {
     return false;
   }
   /// Returns the largest vectorization factor used in the list of
   /// vector functions.
   unsigned getWidestVF(StringRef ScalarF) const {
-    return Impl->getWidestVF(ScalarF);
+    return Impl->getWidestVF(ScalarF, VectLibrary);
   }
 
   /// Check if the function "F" is listed in a library known to LLVM.
   bool isKnownVectorFunctionInLibrary(StringRef F) const {
     return this->isFunctionVectorizable(F);
   }
 };
 

llvm/lib/Analysis/InlineCost.cpp

cl::desc("Minimum block frequency, expressed as a multiple of caller's "
              "entry frequency, for a callsite to be hot in the absence of "
              "profile information."));
 
 static cl::opt<bool> OptComputeFullInlineCost(
     "inline-cost-full", cl::Hidden, cl::init(false), cl::ZeroOrMore,
     cl::desc("Compute the full inline cost of a call site even when the cost "
              "exceeds the threshold."));
 
-static cl::opt<bool> InlineCallerSupersetNoBuiltin(
-    "inline-caller-superset-nobuiltin", cl::Hidden, cl::init(true),
-    cl::ZeroOrMore,
-    cl::desc("Allow inlining when caller has a superset of callee's nobuiltin "
+static cl::opt<bool> InlineCallerSupersetTLI(
+    "inline-caller-superset-tli", cl::Hidden, cl::init(true), cl::ZeroOrMore,
+    cl::desc("Allow inlining when caller has a superset of callee's TLI "
              "attributes."));
 
 namespace {
 class InlineCostCallAnalyzer;
 
 // This struct is used to store information about inline cost of a
 // particular instruction
 struct InstructionCostDetail {
static bool functionsHaveCompatibleAttributes(
     function_ref<const TargetLibraryInfo &(Function &)> &GetTLI) {
   // Note that CalleeTLI must be a copy not a reference. The legacy pass manager
   // caches the most recently created TLI in the TargetLibraryInfoWrapperPass
   // object, and always returns the same object (which is overwritten on each
   // GetTLI call). Therefore we copy the first result.
   auto CalleeTLI = GetTLI(*Callee);
   return TTI.areInlineCompatible(Caller, Callee) &&
          GetTLI(*Caller).areInlineCompatible(CalleeTLI,
-                                             InlineCallerSupersetNoBuiltin) &&
+                                             InlineCallerSupersetTLI) &&
          AttributeFuncs::areInlineCompatible(*Caller, *Callee);
 }
 
 int llvm::getCallsiteCost(CallBase &Call, const DataLayout &DL) {
   int Cost = 0;
   for (unsigned I = 0, E = Call.arg_size(); I != E; ++I) {
     if (Call.isByValArgument(I)) {
       // We approximate the number of loads and stores needed by dividing the

llvm/lib/Analysis/TargetLibraryInfo.cpp

static void initialize(TargetLibraryInfoImpl &TLI, const Triple &T,
   // optimizations, so this situation should be fixed.
   if (T.isNVPTX()) {
     TLI.disableAllFunctions();
     TLI.setAvailable(LibFunc_nvvm_reflect);
   } else {
     TLI.setUnavailable(LibFunc_nvvm_reflect);
   }
 
-  TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
+  TLI.addAllVectorizableFunctions();
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
   // Default to everything being available.
   memset(AvailableArray, -1, sizeof(AvailableArray));
 
   initialize(*this, Triple(), StandardNames);
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl(const Triple &T) {
   // Default to everything being available.
   memset(AvailableArray, -1, sizeof(AvailableArray));
 
   initialize(*this, T, StandardNames);
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl(const TargetLibraryInfoImpl &TLI)
     : CustomNames(TLI.CustomNames), ShouldExtI32Param(TLI.ShouldExtI32Param),
       ShouldExtI32Return(TLI.ShouldExtI32Return),
       ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
   memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
-  VectorDescs = TLI.VectorDescs;
-  ScalarDescs = TLI.ScalarDescs;
+  for (unsigned i = 0; i < NumVecLibs; i++)
+    VecLibDescs[i] = TLI.VecLibDescs[i];
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl(TargetLibraryInfoImpl &&TLI)
     : CustomNames(std::move(TLI.CustomNames)),
       ShouldExtI32Param(TLI.ShouldExtI32Param),
       ShouldExtI32Return(TLI.ShouldExtI32Return),
       ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
   std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
             AvailableArray);
-  VectorDescs = TLI.VectorDescs;
-  ScalarDescs = TLI.ScalarDescs;
+  for (unsigned i = 0; i < NumVecLibs; i++)
+    VecLibDescs[i] = TLI.VecLibDescs[i];
 }
 
 TargetLibraryInfoImpl &TargetLibraryInfoImpl::operator=(const TargetLibraryInfoImpl &TLI) {
   CustomNames = TLI.CustomNames;
   ShouldExtI32Param = TLI.ShouldExtI32Param;
   ShouldExtI32Return = TLI.ShouldExtI32Return;
   ShouldSignExtI32Param = TLI.ShouldSignExtI32Param;
   memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));

 static bool compareWithScalarFnName(const VecDesc &LHS, StringRef S) {
   return LHS.ScalarFnName < S;
 }
 
 static bool compareWithVectorFnName(const VecDesc &LHS, StringRef S) {
   return LHS.VectorFnName < S;
 }
 
-void TargetLibraryInfoImpl::addVectorizableFunctions(ArrayRef<VecDesc> Fns) {
+void TargetLibraryInfoImpl::addAllVectorizableFunctions() {
+  addVectorizableFunctionsFromVecLib(Accelerate, VecLibDescs[Accelerate]);
+  addVectorizableFunctionsFromVecLib(MASSV, VecLibDescs[MASSV]);
+  addVectorizableFunctionsFromVecLib(SVML, VecLibDescs[SVML]);
+}
+
+void TargetLibraryInfoImpl::addVectorizableFunctions(
+    ArrayRef<VecDesc> Fns, VectorLibraryDescriptors &VecLibDesc) {
+  auto &VectorDescs = VecLibDesc.VectorDescs;
+  auto &ScalarDescs = VecLibDesc.ScalarDescs;
   VectorDescs.insert(VectorDescs.end(), Fns.begin(), Fns.end());
   llvm::sort(VectorDescs, compareByScalarFnName);
 
   ScalarDescs.insert(ScalarDescs.end(), Fns.begin(), Fns.end());
   llvm::sort(ScalarDescs, compareByVectorFnName);
 }
 
 void TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib(
-    enum VectorLibrary VecLib) {
+    enum VectorLibrary VecLib, VectorLibraryDescriptors &VetLibDesc) {
   switch (VecLib) {
   case Accelerate: {
     const VecDesc VecFuncs[] = {
     #define TLI_DEFINE_ACCELERATE_VECFUNCS
     #include "llvm/Analysis/VecFuncs.def"
     };
-    addVectorizableFunctions(VecFuncs);
+    addVectorizableFunctions(VecFuncs, VetLibDesc);
     break;
   }
   case MASSV: {
     const VecDesc VecFuncs[] = {
     #define TLI_DEFINE_MASSV_VECFUNCS
     #include "llvm/Analysis/VecFuncs.def"
     };
-    addVectorizableFunctions(VecFuncs);
+    addVectorizableFunctions(VecFuncs, VetLibDesc);
     break;
   }
   case SVML: {
     const VecDesc VecFuncs[] = {
     #define TLI_DEFINE_SVML_VECFUNCS
     #include "llvm/Analysis/VecFuncs.def"
     };
-    addVectorizableFunctions(VecFuncs);
+    addVectorizableFunctions(VecFuncs, VetLibDesc);
     break;
   }
-  case NoLibrary:
+  default:
+    llvm_unreachable("Unexpected vector library");
     break;
   }
 }
 
-bool TargetLibraryInfoImpl::isFunctionVectorizable(StringRef funcName) const {
+bool TargetLibraryInfoImpl::isFunctionVectorizable(StringRef funcName,
+                                                   VectorLibrary vecLib) const {
   funcName = sanitizeFunctionName(funcName);
-  if (funcName.empty())
+  if (funcName.empty() || vecLib >= NumVecLibs)
     return false;
 
+  auto &VectorDescs = VecLibDescs[vecLib].VectorDescs;
   std::vector<VecDesc>::const_iterator I =
       llvm::lower_bound(VectorDescs, funcName, compareWithScalarFnName);
   return I != VectorDescs.end() && StringRef(I->ScalarFnName) == funcName;
 }
 
-StringRef TargetLibraryInfoImpl::getVectorizedFunction(StringRef F,
-                                                       unsigned VF) const {
+StringRef
+TargetLibraryInfoImpl::getVectorizedFunction(StringRef F, unsigned VF,
+                                             VectorLibrary vecLib) const {
   F = sanitizeFunctionName(F);
-  if (F.empty())
+  if (F.empty() || vecLib >= NumVecLibs)
     return F;
+  auto &VectorDescs = VecLibDescs[vecLib].VectorDescs;
   std::vector<VecDesc>::const_iterator I =
       llvm::lower_bound(VectorDescs, F, compareWithScalarFnName);
   while (I != VectorDescs.end() && StringRef(I->ScalarFnName) == F) {
     if (I->VectorizationFactor == VF)
       return I->VectorFnName;
     ++I;
   }
   return StringRef();
 }
 
-StringRef TargetLibraryInfoImpl::getScalarizedFunction(StringRef F,
-                                                       unsigned &VF) const {
+StringRef
+TargetLibraryInfoImpl::getScalarizedFunction(StringRef F, unsigned &VF,
+                                             VectorLibrary vecLib) const {
   F = sanitizeFunctionName(F);
-  if (F.empty())
+  if (F.empty() || vecLib >= NumVecLibs)
     return F;
 
+  auto &VectorDescs = VecLibDescs[vecLib].VectorDescs;
+  auto &ScalarDescs = VecLibDescs[vecLib].ScalarDescs;
   std::vector<VecDesc>::const_iterator I =
       llvm::lower_bound(ScalarDescs, F, compareWithVectorFnName);
   if (I == VectorDescs.end() || StringRef(I->VectorFnName) != F)
     return StringRef();
   VF = I->VectorizationFactor;
   return I->ScalarFnName;
 }
 
+TargetLibraryInfo::TargetLibraryInfo(const TargetLibraryInfoImpl &Impl,
+                                     Optional<const Function *> F)
+    : Impl(&Impl), OverrideAsUnavailable(NumLibFuncs) {
+  if (!F)
+    return;
+
+  StringRef VectLib = (*F)->getFnAttribute("veclib").getValueAsString();
+  if (!VectLib.empty())
+    VectLibrary = getVecLibFromName(VectLib);
+  else
+    VectLibrary = ClVectorLibrary;
+
+  if ((*F)->hasFnAttribute("no-builtins"))
+    disableAllFunctions();
+  else {
+    // Disable individual libc/libm calls in TargetLibraryInfo.
+    LibFunc LF;
+    AttributeSet FnAttrs = (*F)->getAttributes().getFnAttributes();
+    for (const Attribute &Attr : FnAttrs) {
+      if (!Attr.isStringAttribute())
+        continue;
+      auto AttrStr = Attr.getKindAsString();
+      if (!AttrStr.consume_front("no-builtin-"))
+        continue;
+      if (getLibFunc(AttrStr, LF))
+        setUnavailable(LF);
+    }
+  }
+}
+
 TargetLibraryInfo TargetLibraryAnalysis::run(const Function &F,
                                              FunctionAnalysisManager &) {
   if (!BaselineInfoImpl)
     BaselineInfoImpl =
         TargetLibraryInfoImpl(Triple(F.getParent()->getTargetTriple()));
   return TargetLibraryInfo(*BaselineInfoImpl, &F);
 }
 
 unsigned TargetLibraryInfoImpl::getWCharSize(const Module &M) const {
   if (auto *ShortWChar = cast_or_null<ConstantAsMetadata>(
       M.getModuleFlag("wchar_size")))
     return cast<ConstantInt>(ShortWChar->getValue())->getZExtValue();
   return 0;
 }
 
 TargetLibraryInfoWrapperPass::TargetLibraryInfoWrapperPass()
     : ImmutablePass(ID), TLA(TargetLibraryInfoImpl()) {

 
 // Register the basic pass.
 INITIALIZE_PASS(TargetLibraryInfoWrapperPass, "targetlibinfo",
                 "Target Library Information", false, true)
 char TargetLibraryInfoWrapperPass::ID = 0;
 
 void TargetLibraryInfoWrapperPass::anchor() {}
 
-unsigned TargetLibraryInfoImpl::getWidestVF(StringRef ScalarF) const {
+unsigned TargetLibraryInfoImpl::getWidestVF(StringRef ScalarF,
+                                            VectorLibrary vecLib) const {
   ScalarF = sanitizeFunctionName(ScalarF);
-  if (ScalarF.empty())
+  if (ScalarF.empty() || vecLib >= NumVecLibs)
     return 1;
 
   unsigned VF = 1;
+  auto &VectorDescs = VecLibDescs[vecLib].VectorDescs;
   std::vector<VecDesc>::const_iterator I =
       llvm::lower_bound(VectorDescs, ScalarF, compareWithScalarFnName);
   while (I != VectorDescs.end() && StringRef(I->ScalarFnName) == ScalarF) {
     if (I->VectorizationFactor > VF)
       VF = I->VectorizationFactor;
     ++I;
   }
   return VF;
 }

llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll

 ; Test to ensure no inlining is allowed into a caller with fewer nobuiltin attributes.
 ; RUN: opt < %s -mtriple=x86_64-unknown-linux-gnu -S -inline | FileCheck %s
 ; RUN: opt < %s -mtriple=x86_64-unknown-linux-gnu -S -passes='cgscc(inline)' | FileCheck %s
 
 ; Make sure we don't inline callees into a caller with a superset of the
-; no builtin attributes when -inline-caller-superset-nobuiltin=false.
-; RUN: opt < %s -inline-caller-superset-nobuiltin=false -mtriple=x86_64-unknown-linux-gnu -S -passes='cgscc(inline)' | FileCheck %s --check-prefix=NOSUPERSET
+; no builtin attributes when -inline-caller-superset-tli=false.
+; RUN: opt < %s -inline-caller-superset-tli=false -mtriple=x86_64-unknown-linux-gnu -S -passes='cgscc(inline)' | FileCheck %s --check-prefix=NOSUPERSET
 
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-linux-gnu"
 
 define i32 @allbuiltins() {
 entry:
   %call = call i32 (...) @externalfunc()
   ret i32 %call

llvm/test/Transforms/Inline/veclib-compat.ll

+; RUN: opt < %s -inline -inline-caller-superset-tli=true -S | FileCheck %s --check-prefixes=COMMON
+; RUN: opt < %s -passes='cgscc(inline)' -inline-caller-superset-tli=true -S | FileCheck %s --check-prefixes=COMMON
+; RUN: opt < %s -inline -inline-caller-superset-tli=false -S | FileCheck %s --check-prefixes=NOSUPERSET,COMMON
+; RUN: opt < %s -passes='cgscc(inline)' -inline-caller-superset-tli=false -S | FileCheck %s --check-prefixes=NOSUPERSET,COMMON
+
+
+
+define i32 @callee_svml(i8 %X) #0 {
+entry:
+  ret i32 1
+}
+
+define i32 @callee_massv(i8 %X) #1 {
+entry:
+  ret i32 1
+}
+
+define i32 @callee_nolibrary(i8 %X) {
+entry:
+  ret i32 1
+}
+
+define i32 @caller_svml() #0 {
+; COMMON-LABEL: define i32 @caller_svml()
+entry:
+  %rslt = call i32 @callee_massv(i8 123)
+; COMMON: call i32 @callee_massv
+  %tmp1 = call i32 @callee_nolibrary(i8 123)
+; NOSUPERSET: call i32 @callee_nolibrary
+  %tmp2 = call i32 @callee_svml(i8 123)
+; COMMON-NOT: call
+  ret i32 %rslt
+}
+
+define i32 @caller_nolibrary() {
+; COMMON-LABEL: define i32 @caller_nolibrary()
+entry:
+  %rslt = call i32 @callee_svml(i8 123)
+; COMMON: call i32 @callee_svml
+  %tmp1 = call i32 @callee_massv(i8 123)
+; COMMON: call i32 @callee_massv
+  %tmp2 = call i32 @callee_nolibrary(i8 123)
+; COMMON-NOT: call
+  ret i32 %rslt
+}
+
+attributes #0 = { "veclib"="SVML" }
+attributes #1 = { "veclib"="MASSV" }
 No newline at end of file