[llvm] Fix mechanism propagating mangled names for TLI function mappings (PR #66656)

via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 18 09:15:29 PDT 2023


================
@@ -163,18 +177,18 @@ class TargetLibraryInfoImpl {
   /// Return true if the function F has a vector equivalent with vectorization
   /// factor VF.
   bool isFunctionVectorizable(StringRef F, const ElementCount &VF) const {
-    return !(getVectorizedFunction(F, VF, false).empty() &&
-             getVectorizedFunction(F, VF, true).empty());
+    return !(getVectorizedFunction(F, VF, false).first.empty() &&
+             getVectorizedFunction(F, VF, true).first.empty());
   }
 
   /// Return true if the function F has a vector equivalent with any
   /// vectorization factor.
   bool isFunctionVectorizable(StringRef F) 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, const ElementCount &VF,
-                                  bool Masked) const;
+  /// Return the name of the equivalent of F, vectorized with factor VF and it's
+  /// mangled name. If no such mapping exists, return empty strings.
+  std::pair<StringRef, StringRef>
+  getVectorizedFunction(StringRef F, const ElementCount &VF, bool Masked) const;
----------------
paulwalker-arm wrote:

This feels clunky and I think the original interface is just wrong because it's not going to scale well with different variants for the same scalar functions.  I think it's best to return the complete record (essentially turn VecDesc into a class) so that all the related information is kept together.

NOTE: I'm not saying you need to convert all the code paths, feel free to sit the old interface on top of new one and then just use the new one where you need it (i.e. when you need access to the mangle string).

https://github.com/llvm/llvm-project/pull/66656


More information about the llvm-commits mailing list