[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

In D77925#2236519 , @tejohnson wrote:

> In D77925#2229484 , @mehdi_amini 
> wrote:
>
>> Overall that would likely work for XLA. Something I'd like to mention though 
>> in response to:
>>
>>> The veclib type is also tied to the accepted values for -fveclib, which is 
>>> a list of supported lib,
>>
>> `-fveclib` is a Clang thing, it shouldn't limit what LLVM does. Of course 
>> LLVM needs to support Clang, but does not have to inherit the limitation of 
>> map 1:1 to Clang UI.
>> In particular as a library, it isn't clear why we would make the choice to 
>> write LLVM VecLib support this way.

Fair point. I was trying to differentiate the accepted veclib from any other 
custom lib. I guess it's somewhat like namespace, even though built-in ones are 
different from user defined ones, the underlying support doesn't have to 
differentiate them.

> Is there any benefit to keeping a closed list like this in LLVM? If not (and 
> presumably clang is checking for valid values of -fveclib), then I think I 
> agree with @mehdi_amini. Unless there is an efficiency reason for doing it 
> via an enum. It's been awhile since I looked through this code in detail...

I think performance should be fine, the attributes on functions are in string 
form already. TLI compatibility check will involve a string compare, but a 
short string compare shouldn't be disastrous. I was mainly trying to let LLVM 
match clang's supported list.

Will get back to this hopefully next week.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925

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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

In D77925#2229484 , @mehdi_amini wrote:

> Overall that would likely work for XLA. Something I'd like to mention though 
> in response to:
>
>> The veclib type is also tied to the accepted values for -fveclib, which is a 
>> list of supported lib,
>
> `-fveclib` is a Clang thing, it shouldn't limit what LLVM does. Of course 
> LLVM needs to support Clang, but does not have to inherit the limitation of 
> map 1:1 to Clang UI.
> In particular as a library, it isn't clear why we would make the choice to 
> write LLVM VecLib support this way.

Is there any benefit to keeping a closed list like this in LLVM? If not (and 
presumably clang is checking for valid values of -fveclib), then I think I 
agree with @mehdi_amini. Unless there is an efficiency reason for doing it via 
an enum. It's been awhile since I looked through this code in detail...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925

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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

Overall that would likely work for XLA. Something I'd like to mention though in 
response to:

> The veclib type is also tied to the accepted values for -fveclib, which is a 
> list of supported lib,

`-fveclib` is a Clang thing, it shouldn't limit what LLVM does. Of course LLVM 
needs to support Clang, but does not have to inherit the limitation of map 1:1 
to Clang UI.
In particular as a library, it isn't clear why we would make the choice to 
write LLVM VecLib support this way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925

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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

In D77925#2220177 , @wenlei wrote:

> In D77925#2220169 , @mehdi_amini 
> wrote:
>
>> I rather have a non closed list of veclib: if you just have a map keyed by 
>> string instead of an enum it should just work out?
>
> The veclib type is also tied to the accepted values for `-fveclib`, which is 
> a list of supported lib, anything outside of the list is rejected with error. 
> If you want to allow arbitrary strings as key, it's inconsistent with the 
> restricted/closed values for `-fveclib`. So basically there's no openness 
> from clang/llvm tool, while there was some openness through the libraries. I 
> think by introducing a "Custom" veclib type, we can solve the impedance 
> mismatch there. And in the XLA case, conceptually it's an indeed a custom 
> veclib, right? Functionality-wise, `Custom` should just work for XLA usage 
> too.

@mehdi_amini @tejohnson thoughts on the above?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925

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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

In D77925#2220169 , @mehdi_amini wrote:

> I rather have a non closed list of veclib: if you just have a map keyed by 
> string instead of an enum it should just work out?

The veclib type is also tied to the accepted values for `-fveclib`, which is a 
list of supported lib, anything outside of the list is rejected with error. If 
you want to allow arbitrary strings as key, it's inconsistent with the 
restricted/closed values for `-fveclib`. So basically there's no openness from 
clang/llvm tool, while there was some openness through the libraries. I think 
by introducing a "Custom" veclib type, we can solve the impedance mismatch 
there. And in the XLA case, conceptually it's an indeed a custom veclib, right? 
Functionality-wise, `Custom` should just work for XLA usage too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925

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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini added a comment.

I rather have a non closed list of veclib: if you just have a map keyed by 
string instead of an enum it should just work out?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925

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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

In D77925#2016326 , @tejohnson wrote:

> In D77925#2016299 , @wenlei wrote:
>
>> @mehdi_amini @tejohnson When can we re-land this (with tweaks)? I'm under 
>> the impression that a test case demonstrating the 3rd party usage will be 
>> added very soon after this revert, then we can tweak the original patch to 
>> accommodate that usage, and re-land asap. Or am I missing something there? 
>> I'd like to get this unblocked asap. Currently we have to keep this as a 
>> private patch on our end which is a bit cumbersome, and I think this one can 
>> be useful for others too. Thanks..
>
> @bkramer can you work with Wenlei on this (original patch is D77632 
> ).
>
> @wenlei, in the meantime you can see the use case here:
> https://github.com/tensorflow/tensorflow/blob/master/tensorflow/compiler/xla/service/cpu/compiler_functor.cc#L198
> for revising the patch.

Thanks for pointer, @tejohnson. Looks like we need a way for others to provide 
a set of vector functions. How about we introduced a dedicated VecLib type 
`Custom`, in addition to the existing ones (Accelerate, SVML and MASSV), and 
expose a public API `addCustomVectorizableFunctions(ArrayRef Fns)` for 
TLII to allow registering custom function list. This way we preserve the 
openness through `Custom`, but also keep it clean and structured.

Then for XLA, you just need to specify `-fveclib=Custom` and call 
`addCustomVectorizableFunctions` instead of `addVectorizableFunctions`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925

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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

In D77925#2016299 , @wenlei wrote:

> @mehdi_amini @tejohnson When can we re-land this (with tweaks)? I'm under the 
> impression that a test case demonstrating the 3rd party usage will be added 
> very soon after this revert, then we can tweak the original patch to 
> accommodate that usage, and re-land asap. Or am I missing something there? 
> I'd like to get this unblocked asap. Currently we have to keep this as a 
> private patch on our end which is a bit cumbersome, and I think this one can 
> be useful for others too. Thanks..


@bkramer can you work with Wenlei on this (original patch is D77632 
).

@wenlei, in the meantime you can see the use case here:
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/compiler/xla/service/cpu/compiler_functor.cc#L198
for revising the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925



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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

@mehdi_amini @tejohnson When can we re-land this (with tweaks)? I'm under the 
impression that a test case demonstrating the 3rd party usage will be added 
very soon after this revert, then we can tweak the original patch to 
accommodate that usage, and re-land asap. Or am I missing something there? I'd 
like to get this unblocked asap. Currently we have to keep this as a private 
patch on our end which is a bit cumbersome, and I think this one can be useful 
for others too. Thanks..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925



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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Mehdi AMINI via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925

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
===
--- llvm/test/Transforms/Inline/veclib-compat.ll
+++ /dev/null
@@ -1,48 +0,0 @@
-; 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-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
+; 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
 
 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.addAllVectorizableFunctions();
+  TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
@@ -572,8 +572,8 @@
   ShouldExtI32Return(TLI.ShouldExtI32Return),
   ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
   memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
-  for (unsigned i = 0; i < NumVecLibs; i++)
-VecLibDescs[i] = TLI.VecLibDescs[i];
+  VectorDescs = TLI.VectorDescs;
+  ScalarDescs = TLI.ScalarDescs;
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl(TargetLibraryInfoImpl &)
@@ -583,8 +583,8 @@
   ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
   std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
 AvailableArray);
-  for (unsigned i = 0; i < NumVecLibs; i++)
-VecLibDescs[i] = TLI.VecLibDescs[i];
+  VectorDescs = TLI.VectorDescs;
+  ScalarDescs = TLI.ScalarDescs;
 }
 
 TargetLibraryInfoImpl ::operator=(const TargetLibraryInfoImpl ) {
@@ -1520,16 +1520,7 @@
   return LHS.VectorFnName < S;
 }
 
-void TargetLibraryInfoImpl::addAllVectorizableFunctions() {
-  addVectorizableFunctionsFromVecLib(Accelerate, VecLibDescs[Accelerate]);
-  addVectorizableFunctionsFromVecLib(MASSV, VecLibDescs[MASSV]);
-  addVectorizableFunctionsFromVecLib(SVML, VecLibDescs[SVML]);
-}
-
-void TargetLibraryInfoImpl::addVectorizableFunctions(
-ArrayRef Fns, 

[PATCH] D77925: Revert "[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


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77925



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

[PATCH] D77925: Revert "[TLI] Per-function fveclib for math library used for vectorization"

[Mehdi AMINI via Phabricator via cfe-commits]

mehdi_amini created this revision.
mehdi_amini added a reviewer: tejohnson.
Herald added subscribers: cfe-commits, haicheng, hiraditya, eraman.
Herald added a project: clang.
mehdi_amini added a reviewer: wenlei.
tejohnson accepted this revision.
tejohnson added a comment.
This revision is now accepted and ready to land.

lgtm


This reverts commit 60c642e74be6af86906d9f3d982728be7bd4329f 
.

This patch is making the TLI "closed" for a predefined set of VecLib
while at the moment it is extensible for anyone to customize when using
LLVM as a library.
Reverting while we figure out a way to re-land it without losing the
generality of the current API.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D77925

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
===
--- llvm/test/Transforms/Inline/veclib-compat.ll
+++ /dev/null
@@ -1,48 +0,0 @@
-; 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-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
+; 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
 
 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.addAllVectorizableFunctions();
+  TLI.addVectorizableFunctionsFromVecLib(ClVectorLibrary);
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl() {
@@ -572,8 +572,8 @@
   ShouldExtI32Return(TLI.ShouldExtI32Return),
   ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
   memcpy(AvailableArray, TLI.AvailableArray, sizeof(AvailableArray));
-  for (unsigned i = 0; i < NumVecLibs; i++)
-VecLibDescs[i] = TLI.VecLibDescs[i];
+  VectorDescs = TLI.VectorDescs;
+  ScalarDescs = TLI.ScalarDescs;
 }
 
 TargetLibraryInfoImpl::TargetLibraryInfoImpl(TargetLibraryInfoImpl &)
@@ -583,8 +583,8 @@
   ShouldSignExtI32Param(TLI.ShouldSignExtI32Param) {
   std::move(std::begin(TLI.AvailableArray), std::end(TLI.AvailableArray),
 AvailableArray);
-  for (unsigned i = 0; i < NumVecLibs; i++)
-VecLibDescs[i] = TLI.VecLibDescs[i];
+  VectorDescs = TLI.VectorDescs;
+  ScalarDescs = TLI.ScalarDescs;
 }
 
 TargetLibraryInfoImpl