================
@@ -1296,11 +1296,52 @@ def CIR_CXXAssignAttr : CIR_Attr<"CXXAssign", 
"cxx_assign"> {
 // FuncInfoAttr
 
//===----------------------------------------------------------------------===//
 
+// The standard library entities the identity tag can name. Each entry
+// pairs with one raised operation in CIRStdOps.td.
+def CIR_KnownFuncKind : CIR_I32EnumAttr<"KnownFuncKind",
+    "known standard library entity", [
+  I32EnumAttrCase<"StdFind", 1, "std_find">,
+]> {
+  let genSpecializedAttr = 0;
+}
+
+def CIR_FuncIdentityAttr : CIR_Attr<"FuncIdentity", "func_identity"> {
+  let summary = "Identifies a function as a known standard library entity";
+  let description = [{
+    Names the standard library entity a function represents, so that
+    transformations can recognize calls to well known library functions
+    without decoding mangled symbol names.
+
+    The tag names the whole entity. For `std_find` that is the free
+    function named `find` in the `std` namespace, so a member function, a
+    static member, or an operator can never carry the tag. Inline
+    namespaces, such as the versioning namespace of libc++, count as part
+    of `std`. The tag never encodes signatures, and a function that
+    matches no known entity carries no attribute.
+
+    Example:
+    ```
+    #cir.func_identity<std_find>
+    ```
+  }];
+
+  let parameters = (ins
+    EnumParameter<CIR_KnownFuncKind>:$kind
----------------
erichkeane wrote:

Yep, just something to think about.  It seems to me that we want to eventually 
represent the entirety of the STL in SOME way.  I could see the ability to 
recognize member `push_back` eventually, and be able to ALSO record whether it 
was `std::vector`, `std::list`, etc.  At one point, we might consider listing 
the 'primary' template argument here too (that is, we don't care about the 
allocator, but we DO care about vectors primary type.

Just something to be thinking about.

https://github.com/llvm/llvm-project/pull/208854
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to