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

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

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=60c642e74be6af86906d9f3d982728be7bd4329f=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.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

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` 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).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

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=60c642e74be6af86906d9f3d982728be7bd4329f=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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

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` 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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

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` 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?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

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=60c642e74be6af86906d9f3d982728be7bd4329f=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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

In D77632#1974015 , @nikic wrote:

> This change causes a ~0.5% compile-time regressions: 
> http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88=60c642e74be6af86906d9f3d982728be7bd4329f=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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

This change causes a ~0.5% compile-time regressions: 
http://llvm-compile-time-tracker.com/compare.php?from=5b18b6e9a84d985c0a907009fb71de7c1943bc88=60c642e74be6af86906d9f3d982728be7bd4329f=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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Wenlei He via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG60c642e74be6: [TLI] Per-function fveclib for math library 
used for vectorization (authored by wenlei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/libcalls-veclib.c
  llvm/include/llvm/Analysis/TargetLibraryInfo.h
  llvm/lib/Analysis/InlineCost.cpp
  llvm/lib/Analysis/TargetLibraryInfo.cpp
  llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
  llvm/test/Transforms/Inline/veclib-compat.ll

Index: llvm/test/Transforms/Inline/veclib-compat.ll
===
--- /dev/null
+++ llvm/test/Transforms/Inline/veclib-compat.ll
@@ -0,0 +1,48 @@
+; 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
Index: llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
===
--- llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
+++ llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
@@ -3,8 +3,8 @@
 ; 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"
Index: llvm/lib/Analysis/TargetLibraryInfo.cpp
===
--- llvm/lib/Analysis/TargetLibraryInfo.cpp
+++ llvm/lib/Analysis/TargetLibraryInfo.cpp
@@ -550,7 +550,7 @@
 TLI.setUnavailable(LibFunc_nvvm_reflect);
   }
 
-  TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
+  TLI.addAllVectorizableFunctions();
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
@@ -572,8 +572,8 @@
   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 &)
@@ -583,8 +583,8 @@
   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 ::operator=(const TargetLibraryInfoImpl ) {
@@ -1520,7 +1520,16 @@
   return LHS.VectorFnName < S;
 }
 
-void TargetLibraryInfoImpl::addVectorizableFunctions(ArrayRef Fns) {
+void TargetLibraryInfoImpl::addAllVectorizableFunctions() {
+  addVectorizableFunctionsFromVecLib(Accelerate, VecLibDescs[Accelerate]);
+  addVectorizableFunctionsFromVecLib(MASSV, VecLibDescs[MASSV]);
+  addVectorizableFunctionsFromVecLib(SVML, VecLibDescs[SVML]);
+}
+
+void 

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

[Wenlei He via Phabricator via cfe-commits]

wenlei updated this revision to Diff 256465.
wenlei marked an inline comment as done.
wenlei added a comment.

rebase, update test


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/libcalls-veclib.c
  llvm/include/llvm/Analysis/TargetLibraryInfo.h
  llvm/lib/Analysis/InlineCost.cpp
  llvm/lib/Analysis/TargetLibraryInfo.cpp
  llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
  llvm/test/Transforms/Inline/veclib-compat.ll

Index: llvm/test/Transforms/Inline/veclib-compat.ll
===
--- /dev/null
+++ llvm/test/Transforms/Inline/veclib-compat.ll
@@ -0,0 +1,48 @@
+; 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
Index: llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
===
--- llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
+++ llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
@@ -3,8 +3,8 @@
 ; 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"
Index: llvm/lib/Analysis/TargetLibraryInfo.cpp
===
--- llvm/lib/Analysis/TargetLibraryInfo.cpp
+++ llvm/lib/Analysis/TargetLibraryInfo.cpp
@@ -550,7 +550,7 @@
 TLI.setUnavailable(LibFunc_nvvm_reflect);
   }
 
-  TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
+  TLI.addAllVectorizableFunctions();
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
@@ -572,8 +572,8 @@
   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 &)
@@ -583,8 +583,8 @@
   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 ::operator=(const TargetLibraryInfoImpl ) {
@@ -1520,7 +1520,16 @@
   return LHS.VectorFnName < S;
 }
 
-void TargetLibraryInfoImpl::addVectorizableFunctions(ArrayRef Fns) {
+void TargetLibraryInfoImpl::addAllVectorizableFunctions() {
+  addVectorizableFunctionsFromVecLib(Accelerate, VecLibDescs[Accelerate]);
+  addVectorizableFunctionsFromVecLib(MASSV, VecLibDescs[MASSV]);
+  addVectorizableFunctionsFromVecLib(SVML, VecLibDescs[SVML]);
+}
+
+void TargetLibraryInfoImpl::addVectorizableFunctions(
+ArrayRef Fns, 

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

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson accepted this revision.
tejohnson added a comment.
This revision is now accepted and ready to land.

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




Comment at: llvm/test/Transforms/Inline/veclib-compat.ll:28
+  %rslt = call i32 @callee_massv(i8 123)
+; SUPERSET: call i32 @callee_massv
+  %tmp1 = call i32 @callee_nolibrary(i8 123)

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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Wenlei He via Phabricator via cfe-commits]

wenlei marked 4 inline comments as done.
wenlei added inline comments.



Comment at: llvm/include/llvm/Analysis/TargetLibraryInfo.h:272
+else
+  VectLibrary = Impl.ClVectorLibrary;
+

tejohnson wrote:
> wenlei wrote:
> > tejohnson wrote:
> > > 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.
> > 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.  
> 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.
Ok, I moved it to .cpp, thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Wenlei He via Phabricator via cfe-commits]

wenlei updated this revision to Diff 256437.
wenlei marked an inline comment as done.
wenlei added a comment.
Herald added subscribers: haicheng, eraman.

address feedback


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/libcalls-veclib.c
  llvm/include/llvm/Analysis/TargetLibraryInfo.h
  llvm/lib/Analysis/InlineCost.cpp
  llvm/lib/Analysis/TargetLibraryInfo.cpp
  llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
  llvm/test/Transforms/Inline/veclib-compat.ll

Index: llvm/test/Transforms/Inline/veclib-compat.ll
===
--- /dev/null
+++ llvm/test/Transforms/Inline/veclib-compat.ll
@@ -0,0 +1,50 @@
+; RUN: opt < %s -inline -inline-caller-superset-tli=true -S | FileCheck %s --check-prefixes=SUPERSET,COMMON
+; RUN: opt < %s -passes='cgscc(inline)' -inline-caller-superset-tli=true -S | FileCheck %s --check-prefixes=SUPERSET,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 {
+; SUPERSET-LABEL: define i32 @caller_svml()
+; NOSUPERSET-LABEL: define i32 @caller_svml()
+entry:
+  %rslt = call i32 @callee_massv(i8 123)
+; SUPERSET: call i32 @callee_massv
+  %tmp1 = call i32 @callee_nolibrary(i8 123)
+; NOSUPERSET: call i32 @callee_nolibrary
+  %tmp2 = call i32 @callee_svml(i8 123)
+; SUPERSET-NOT: call
+; NOSUPERSET-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
Index: llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
===
--- llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
+++ llvm/test/Transforms/Inline/inline-no-builtin-compatible.ll
@@ -3,8 +3,8 @@
 ; 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"
Index: llvm/lib/Analysis/TargetLibraryInfo.cpp
===
--- llvm/lib/Analysis/TargetLibraryInfo.cpp
+++ llvm/lib/Analysis/TargetLibraryInfo.cpp
@@ -550,7 +550,7 @@
 TLI.setUnavailable(LibFunc_nvvm_reflect);
   }
 
-  TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
+  TLI.addAllVectorizableFunctions();
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
@@ -572,8 +572,8 @@
   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 &)
@@ -583,8 +583,8 @@
   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 ::operator=(const TargetLibraryInfoImpl ) {
@@ -1520,7 +1520,16 @@
   return LHS.VectorFnName < S;
 }
 
-void TargetLibraryInfoImpl::addVectorizableFunctions(ArrayRef Fns) {
+void TargetLibraryInfoImpl::addAllVectorizableFunctions() {
+  addVectorizableFunctionsFromVecLib(Accelerate, VecLibDescs[Accelerate]);
+  addVectorizableFunctionsFromVecLib(MASSV, VecLibDescs[MASSV]);
+  

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

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added inline comments.



Comment at: llvm/include/llvm/Analysis/TargetLibraryInfo.h:272
+else
+  VectLibrary = Impl.ClVectorLibrary;
+

wenlei wrote:
> tejohnson wrote:
> > 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.
> 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.  
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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Wenlei He via Phabricator via cfe-commits]

wenlei marked 4 inline comments as done.
wenlei added inline comments.



Comment at: llvm/include/llvm/Analysis/TargetLibraryInfo.h:272
+else
+  VectLibrary = Impl.ClVectorLibrary;
+

tejohnson wrote:
> 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.
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.  



Comment at: llvm/lib/Analysis/TargetLibraryInfo.cpp:577
   memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
-  VectorDescs = TLI.VectorDescs;
-  ScalarDescs = TLI.ScalarDescs;
+  for (unsigned i = 0; i < sizeof(TLI.VecLibDescs) / 
sizeof(TLI.VecLibDescs[0]);
+   i++)

tejohnson wrote:
> Why not just have "i < NumVecLibs"?
Good catch, thanks..


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

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




Comment at: llvm/include/llvm/Analysis/TargetLibraryInfo.h:272
+else
+  VectLibrary = Impl.ClVectorLibrary;
+

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.



Comment at: llvm/include/llvm/Analysis/TargetLibraryInfo.h:318
bool AllowCallerSuperset) const {
 if (!AllowCallerSuperset)
+  return VectLibrary == CalleeTLI.VectLibrary &&

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.



Comment at: llvm/lib/Analysis/TargetLibraryInfo.cpp:577
   memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
-  VectorDescs = TLI.VectorDescs;
-  ScalarDescs = TLI.ScalarDescs;
+  for (unsigned i = 0; i < sizeof(TLI.VecLibDescs) / 
sizeof(TLI.VecLibDescs[0]);
+   i++)

Why not just have "i < NumVecLibs"?



Comment at: llvm/lib/Analysis/TargetLibraryInfo.cpp:590
 AvailableArray);
-  VectorDescs = TLI.VectorDescs;
-  ScalarDescs = TLI.ScalarDescs;
+  for (unsigned i = 0; i < sizeof(TLI.VecLibDescs) / 
sizeof(TLI.VecLibDescs[0]);
+   i++)

ditto



Comment at: llvm/lib/Analysis/TargetLibraryInfo.cpp:1574
+  case NumVecLibs:
 break;
   }

Should these two be llvm_unreachable?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Wenlei He via Phabricator via cfe-commits]

wenlei updated this revision to Diff 256350.
wenlei added a comment.

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


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/libcalls-veclib.c
  llvm/include/llvm/Analysis/TargetLibraryInfo.h
  llvm/lib/Analysis/TargetLibraryInfo.cpp
  llvm/test/Transforms/Inline/veclib-compat.ll

Index: llvm/test/Transforms/Inline/veclib-compat.ll
===
--- /dev/null
+++ llvm/test/Transforms/Inline/veclib-compat.ll
@@ -0,0 +1,43 @@
+; RUN: opt < %s -inline -S | FileCheck %s
+; RUN: opt < %s -passes='cgscc(inline)' -S | FileCheck %s
+
+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 {
+; CHECK-LABEL: define i32 @caller_svml()
+entry:
+  %rslt = call i32 @callee_massv(i8 123)
+; CHECK: call i32 @callee_massv
+  %tmp1 = call i32 @callee_svml(i8 123)
+  %tmp2 = call i32 @callee_nolibrary(i8 123)
+; CHECK-NOT: call
+  ret i32 %rslt
+}
+
+define i32 @caller_nolibrary() {
+; CHECK-LABEL: define i32 @caller_nolibrary()
+entry:
+  %rslt = call i32 @callee_svml(i8 123)
+; CHECK: call i32 @callee_svml
+  %tmp1 = call i32 @callee_massv(i8 123)
+; CHECK: call i32 @callee_massv
+  %tmp2 = call i32 @callee_nolibrary(i8 123)
+; CHECK-NOT: call
+  ret i32 %rslt
+}
+
+attributes #0 = { "veclib"="SVML" }
+attributes #1 = { "veclib"="MASSV" }
\ No newline at end of file
Index: llvm/lib/Analysis/TargetLibraryInfo.cpp
===
--- llvm/lib/Analysis/TargetLibraryInfo.cpp
+++ llvm/lib/Analysis/TargetLibraryInfo.cpp
@@ -550,7 +550,8 @@
 TLI.setUnavailable(LibFunc_nvvm_reflect);
   }
 
-  TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
+  TLI.addAllVectorizableFunctions();
+  TLI.setClVectorLibrary(ClVectorLibrary);
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
@@ -570,21 +571,25 @@
 TargetLibraryInfoImpl::TargetLibraryInfoImpl(const TargetLibraryInfoImpl )
 : CustomNames(TLI.CustomNames), ShouldExtI32Param(TLI.ShouldExtI32Param),
   ShouldExtI32Return(TLI.ShouldExtI32Return),
-  ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
+  ShouldSignExtI32Param(TLI.ShouldSignExtI32Param),
+  ClVectorLibrary(TLI.ClVectorLibrary) {
   memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
-  VectorDescs = TLI.VectorDescs;
-  ScalarDescs = TLI.ScalarDescs;
+  for (unsigned i = 0; i < sizeof(TLI.VecLibDescs) / sizeof(TLI.VecLibDescs[0]);
+   i++)
+VecLibDescs[i] = TLI.VecLibDescs[i];
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl(TargetLibraryInfoImpl &)
 : CustomNames(std::move(TLI.CustomNames)),
   ShouldExtI32Param(TLI.ShouldExtI32Param),
   ShouldExtI32Return(TLI.ShouldExtI32Return),
-  ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
+  ShouldSignExtI32Param(TLI.ShouldSignExtI32Param),
+  ClVectorLibrary(TLI.ClVectorLibrary) {
   std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
 AvailableArray);
-  VectorDescs = TLI.VectorDescs;
-  ScalarDescs = TLI.ScalarDescs;
+  for (unsigned i = 0; i < sizeof(TLI.VecLibDescs) / sizeof(TLI.VecLibDescs[0]);
+   i++)
+VecLibDescs[i] = TLI.VecLibDescs[i];
 }
 
 TargetLibraryInfoImpl ::operator=(const TargetLibraryInfoImpl ) {
@@ -1520,7 +1525,16 @@
   return LHS.VectorFnName < S;
 }
 
-void TargetLibraryInfoImpl::addVectorizableFunctions(ArrayRef Fns) {
+void TargetLibraryInfoImpl::addAllVectorizableFunctions() {
+  addVectorizableFunctionsFromVecLib(Accelerate, VecLibDescs[Accelerate]);
+  addVectorizableFunctionsFromVecLib(MASSV, VecLibDescs[MASSV]);
+  addVectorizableFunctionsFromVecLib(SVML, VecLibDescs[SVML]);
+}
+
+void TargetLibraryInfoImpl::addVectorizableFunctions(ArrayRef Fns,
+VectorLibraryDescriptors ) {
+  auto  = VecLibDesc.VectorDescs;
+  auto  = VecLibDesc.ScalarDescs;
   VectorDescs.insert(VectorDescs.end(), Fns.begin(), Fns.end());
   llvm::sort(VectorDescs, compareByScalarFnName);
 
@@ -1529,14 +1543,14 @@
 }
 
 void TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib(
-enum VectorLibrary VecLib) {
+enum VectorLibrary VecLib, VectorLibraryDescriptors ) {
   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: {
@@ -1544,7 +1558,7 @@
 #define TLI_DEFINE_MASSV_VECFUNCS
 #include "llvm/Analysis/VecFuncs.def"
 

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

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

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).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

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




Comment at: clang/lib/CodeGen/CGCall.cpp:1987
 
+  // Attach "vect-lib" attribute to function based on '-fveclib' setting.
+  addVectLibAttributes(FuncAttrs, getCodeGenOpts());

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



Comment at: llvm/include/llvm/Analysis/TargetLibraryInfo.h:47
 /// depends on the triple. So users typically interact with the \c
 /// TargetLibraryInfo wrapper below.
 class TargetLibraryInfoImpl {

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.



Comment at: llvm/include/llvm/Analysis/TargetLibraryInfo.h:91
+  /// Vector library available for vectorization.
+  VectorLibrary VectLibrary = NoLibrary;
 

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.



Comment at: llvm/include/llvm/Analysis/TargetLibraryInfo.h:275
 if (!AllowCallerSuperset)
-  return OverrideAsUnavailable == CalleeTLI.OverrideAsUnavailable;
+  return Impl->VectLibrary == CalleeTLI.Impl->VectLibrary &&
+ OverrideAsUnavailable == CalleeTLI.OverrideAsUnavailable;

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.



Comment at: llvm/lib/Analysis/TargetLibraryInfo.cpp:1549
+assert(VectLibrary == VecLib && 
+   "Conflicting VectorLibrary detected");
+return;

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.



Comment at: llvm/lib/Analysis/TargetLibraryInfo.cpp:1631
+  if (!VectLibName.empty())
+BaselineInfoImpl->addVectorizableFunctionsFromVecLib(VectLibName);
+

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).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Wenlei He via Phabricator via cfe-commits]

wenlei updated this revision to Diff 255703.
wenlei added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/libcalls-veclib.c
  llvm/include/llvm/Analysis/TargetLibraryInfo.h
  llvm/lib/Analysis/TargetLibraryInfo.cpp

Index: llvm/lib/Analysis/TargetLibraryInfo.cpp
===
--- llvm/lib/Analysis/TargetLibraryInfo.cpp
+++ llvm/lib/Analysis/TargetLibraryInfo.cpp
@@ -1528,8 +1528,29 @@
   llvm::sort(ScalarDescs, compareByVectorFnName);
 }
 
+void TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib(
+const StringRef ) {
+  VectorLibrary VecLib = NoLibrary;
+  if (VecLibName == "Accelerate")
+VecLib = Accelerate;
+  else if (VecLibName == "MASSV")
+VecLib = MASSV;
+  else if (VecLibName == "SVML")
+VecLib = SVML;
+  else
+return;
+  addVectorizableFunctionsFromVecLib(VecLib);
+}
+
 void TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib(
 enum VectorLibrary VecLib) {
+  if (VectLibrary != NoLibrary) {
+assert(VectLibrary == VecLib && 
+   "Conflicting VectorLibrary detected");
+return;
+  }
+
+  VectLibrary = VecLib;
   switch (VecLib) {
   case Accelerate: {
 const VecDesc VecFuncs[] = {
@@ -1604,6 +1625,11 @@
   if (!BaselineInfoImpl)
 BaselineInfoImpl =
 TargetLibraryInfoImpl(Triple(F.getParent()->getTargetTriple()));
+
+  StringRef VectLibName = F.getFnAttribute("vect-lib").getValueAsString();
+  if (!VectLibName.empty())
+BaselineInfoImpl->addVectorizableFunctionsFromVecLib(VectLibName);
+
   return TargetLibraryInfo(*BaselineInfoImpl, );
 }
 
Index: llvm/include/llvm/Analysis/TargetLibraryInfo.h
===
--- llvm/include/llvm/Analysis/TargetLibraryInfo.h
+++ llvm/include/llvm/Analysis/TargetLibraryInfo.h
@@ -48,6 +48,22 @@
 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 {
+NoLibrary,  // Don't use any vector library.
+Accelerate, // Use Accelerate framework.
+MASSV,  // IBM MASS vector library.
+SVML// Intel short vector math library.
+  };
+
+private:
   unsigned char AvailableArray[(NumLibFuncs+3)/4];
   llvm::DenseMap CustomNames;
   static StringLiteral const StandardNames[NumLibFuncs];
@@ -71,6 +87,8 @@
   /// Scalarization descriptors - same content as VectorDescs but sorted based
   /// on VectorFnName rather than ScalarFnName.
   std::vector ScalarDescs;
+  /// Vector library available for vectorization.
+  VectorLibrary VectLibrary = NoLibrary;
 
   /// Return true if the function type FTy is valid for the library function
   /// F, regardless of whether the function is available.
@@ -78,20 +96,6 @@
   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.
-  };
-
   TargetLibraryInfoImpl();
   explicit TargetLibraryInfoImpl(const Triple );
 
@@ -148,6 +152,7 @@
   /// Calls addVectorizableFunctions with a known preset of functions for the
   /// given vector library.
   void addVectorizableFunctionsFromVecLib(enum VectorLibrary VecLib);
+  void addVectorizableFunctionsFromVecLib(const StringRef );
 
   /// Return true if the function F has a vector equivalent with vectorization
   /// factor VF.
@@ -261,18 +266,20 @@
   }
 
   /// 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', `vect-lib` attributes.
+  /// When requested, allow inlining into a caller with a superset of the
+  /// callee's attributes, which is conservatively correct.
   bool areInlineCompatible(const TargetLibraryInfo ,
bool AllowCallerSuperset) const {
 

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

[Wenlei He via Phabricator via cfe-commits]

wenlei updated this revision to Diff 255679.
wenlei added a comment.

update


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77632/new/

https://reviews.llvm.org/D77632

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/libcalls-veclib.c
  llvm/include/llvm/Analysis/TargetLibraryInfo.h
  llvm/lib/Analysis/TargetLibraryInfo.cpp

Index: llvm/lib/Analysis/TargetLibraryInfo.cpp
===
--- llvm/lib/Analysis/TargetLibraryInfo.cpp
+++ llvm/lib/Analysis/TargetLibraryInfo.cpp
@@ -1528,8 +1528,29 @@
   llvm::sort(ScalarDescs, compareByVectorFnName);
 }
 
+void TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib(
+const StringRef ) {
+  VectorLibrary VecLib = NoLibrary;
+  if (VecLibName == "Accelerate")
+VecLib = Accelerate;
+  else if (VecLibName == "MASSV")
+VecLib = MASSV;
+  else if (VecLibName == "SVML")
+VecLib = SVML;
+  else
+return;
+  addVectorizableFunctionsFromVecLib(VecLib);
+}
+
 void TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib(
 enum VectorLibrary VecLib) {
+  if (VectLibrary != NoLibrary) {
+assert(VectLibrary == VecLib && 
+   "Conflicting VectorLibrary detected");
+return;
+  }
+
+  VectLibrary = VecLib;
   switch (VecLib) {
   case Accelerate: {
 const VecDesc VecFuncs[] = {
@@ -1604,6 +1625,11 @@
   if (!BaselineInfoImpl)
 BaselineInfoImpl =
 TargetLibraryInfoImpl(Triple(F.getParent()->getTargetTriple()));
+
+  StringRef VectLibName = F.getFnAttribute("vect-lib").getValueAsString();
+  if (!VectLibName.empty())
+BaselineInfoImpl->addVectorizableFunctionsFromVecLib(VectLibName);
+
   return TargetLibraryInfo(*BaselineInfoImpl, );
 }
 
Index: llvm/include/llvm/Analysis/TargetLibraryInfo.h
===
--- llvm/include/llvm/Analysis/TargetLibraryInfo.h
+++ llvm/include/llvm/Analysis/TargetLibraryInfo.h
@@ -48,6 +48,22 @@
 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 {
+NoLibrary,  // Don't use any vector library.
+Accelerate, // Use Accelerate framework.
+MASSV,  // IBM MASS vector library.
+SVML// Intel short vector math library.
+  };
+
+private:
   unsigned char AvailableArray[(NumLibFuncs+3)/4];
   llvm::DenseMap CustomNames;
   static StringLiteral const StandardNames[NumLibFuncs];
@@ -71,6 +87,8 @@
   /// Scalarization descriptors - same content as VectorDescs but sorted based
   /// on VectorFnName rather than ScalarFnName.
   std::vector ScalarDescs;
+  /// Vector library available for vectorization.
+  VectorLibrary VectLibrary = NoLibrary;
 
   /// Return true if the function type FTy is valid for the library function
   /// F, regardless of whether the function is available.
@@ -78,20 +96,6 @@
   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.
-  };
-
   TargetLibraryInfoImpl();
   explicit TargetLibraryInfoImpl(const Triple );
 
@@ -148,6 +152,7 @@
   /// Calls addVectorizableFunctions with a known preset of functions for the
   /// given vector library.
   void addVectorizableFunctionsFromVecLib(enum VectorLibrary VecLib);
+  void addVectorizableFunctionsFromVecLib(const StringRef );
 
   /// Return true if the function F has a vector equivalent with vectorization
   /// factor VF.
@@ -261,18 +266,20 @@
   }
 
   /// 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', `vect-lib` attributes.
+  /// When requested, allow inlining into a caller with a superset of the
+  /// callee's attributes, which is conservatively correct.
   bool areInlineCompatible(const TargetLibraryInfo ,
bool AllowCallerSuperset) const {
 

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

[Wenlei He via Phabricator via cfe-commits]

wenlei created this revision.
Herald added subscribers: cfe-commits, dexonsmith, hiraditya.
Herald added a project: clang.
wenlei edited the summary of this revision.
wenlei added reviewers: tejohnson, hoyFB, spatel, gchatelet.

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.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77632

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/libcalls-veclib.c
  llvm/include/llvm/Analysis/TargetLibraryInfo.h
  llvm/lib/Analysis/TargetLibraryInfo.cpp

Index: llvm/lib/Analysis/TargetLibraryInfo.cpp
===
--- llvm/lib/Analysis/TargetLibraryInfo.cpp
+++ llvm/lib/Analysis/TargetLibraryInfo.cpp
@@ -1528,8 +1528,29 @@
   llvm::sort(ScalarDescs, compareByVectorFnName);
 }
 
+void TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib(
+const StringRef ) {
+  VectorLibrary VecLib = NoLibrary;
+  if (VecLibName == "Accelerate")
+VecLib = Accelerate;
+  else if (VecLibName == "MASSV")
+VecLib = MASSV;
+  else if (VecLibName == "SVML")
+VecLib = SVML;
+  else
+return;
+  addVectorizableFunctionsFromVecLib(VecLib);
+}
+
 void TargetLibraryInfoImpl::addVectorizableFunctionsFromVecLib(
 enum VectorLibrary VecLib) {
+  if (VectLibrary != NoLibrary) {
+assert(VectLibrary == VecLib && 
+   "Conflicting VectorLibrary detected");
+return;
+  }
+
+  VectLibrary = VecLib;
   switch (VecLib) {
   case Accelerate: {
 const VecDesc VecFuncs[] = {
@@ -1604,6 +1625,11 @@
   if (!BaselineInfoImpl)
 BaselineInfoImpl =
 TargetLibraryInfoImpl(Triple(F.getParent()->getTargetTriple()));
+
+  StringRef VectLibName = F.getFnAttribute("vect-lib").getValueAsString();
+  if (!VectLibName.empty())
+BaselineInfoImpl->addVectorizableFunctionsFromVecLib(VectLibName);
+
   return TargetLibraryInfo(*BaselineInfoImpl, );
 }
 
Index: llvm/include/llvm/Analysis/TargetLibraryInfo.h
===
--- llvm/include/llvm/Analysis/TargetLibraryInfo.h
+++ llvm/include/llvm/Analysis/TargetLibraryInfo.h
@@ -48,6 +48,21 @@
 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 {
+NoLibrary,  // Don't use any vector library.
+Accelerate, // Use Accelerate framework.
+MASSV,  // IBM MASS vector library.
+SVML// Intel short vector math library.
+  };
+
   unsigned char AvailableArray[(NumLibFuncs+3)/4];
   llvm::DenseMap CustomNames;
   static StringLiteral const StandardNames[NumLibFuncs];
@@ -71,6 +86,8 @@
   /// Scalarization descriptors - same content as VectorDescs but sorted based
   /// on VectorFnName rather than ScalarFnName.
   std::vector ScalarDescs;
+  /// Vector library available for vectorization.
+  VectorLibrary VectLibrary = NoLibrary;
 
   /// Return true if the function type FTy is valid for the library function
   /// F, regardless of whether the function is available.
@@ -78,20 +95,6 @@
   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.
-  };
-
   TargetLibraryInfoImpl();
   explicit TargetLibraryInfoImpl(const Triple );
 
@@ -148,6 +151,7 @@
   /// Calls addVectorizableFunctions with a known preset of functions for the
   /// given vector library.
   void addVectorizableFunctionsFromVecLib(enum VectorLibrary VecLib);
+  void addVectorizableFunctionsFromVecLib(const StringRef );
 
   /// Return true if the function F has a vector equivalent with vectorization
   /// factor VF.
@@ -261,18 +265,20 @@
   }
 
   /// Determine whether a callee with the given TLI