[NFC] Don't recompute type name

[IanWood1]

This change uses a local static variable to cache the computed StringRef containing the type's name.

I found that RelWithDebInfo builds of MLIR were spending a relatively large amount of time in StringRef::find and I tracked it down to getTypeName which utilizes StringRef methods that are defined in a separate translation unit. This is especially impactful on perf because getTypeName is supposed to be used for debug logging. See an example here:

llvm-project/mlir/include/mlir/IR/Types.h

Lines 294 to 300 in 4b825c7

	#ifndef NDEBUG
	// Check that the current interface isn't an unresolved promise for the
	// given type.
	dialect_extension_detail::handleUseOfUndefinedPromisedInterface(
	type.getDialect(), type.getTypeID(), ConcreteType::getInterfaceID(),
	llvm::getTypeName<ConcreteType>());
	#endif

[llvmbot]

@llvm/pr-subscribers-llvm-support

Author: Ian Wood (IanWood1)

Changes

This change uses a local static variable to cache the StringRef.

I found that RelWithDebInfo builds of MLIR were spending a relatively large amount of time in StringRef::find and I tracked it down to getTypeName which utilizes StringRef methods that are defined in a separate translation unit. This is especially impactful on perf because getTypeName is supposed to be used for debug logging. See an example here:

llvm-project/mlir/include/mlir/IR/Types.h

Lines 294 to 300 in 4b825c7

	#ifndef NDEBUG
	// Check that the current interface isn't an unresolved promise for the
	// given type.
	dialect_extension_detail::handleUseOfUndefinedPromisedInterface(
	type.getDialect(), type.getTypeID(), ConcreteType::getInterfaceID(),
	llvm::getTypeName<ConcreteType>());
	#endif

---

Full diff: https://github.com/llvm/llvm-project/pull/119631.diff

1 Files Affected:

• (modified) llvm/include/llvm/Support/TypeName.h (+18-12)

diff --git a/llvm/include/llvm/Support/TypeName.h b/llvm/include/llvm/Support/TypeName.h
index 9547e76a7fa79b..61ba09c2163047 100644
--- a/llvm/include/llvm/Support/TypeName.h
+++ b/llvm/include/llvm/Support/TypeName.h
@@ -13,18 +13,8 @@
 
 namespace llvm {
 
-/// We provide a function which tries to compute the (demangled) name of a type
-/// statically.
-///
-/// This routine may fail on some platforms or for particularly unusual types.
-/// Do not use it for anything other than logging and debugging aids. It isn't
-/// portable or dependendable in any real sense.
-///
-/// The returned StringRef will point into a static storage duration string.
-/// However, it may not be null terminated and may be some strangely aligned
-/// inner substring of a larger string.
-template <typename DesiredTypeName>
-inline StringRef getTypeName() {
+namespace detail {
+template <typename DesiredTypeName> inline StringRef getTypeNameImpl() {
 #if defined(__clang__) || defined(__GNUC__)
   StringRef Name = __PRETTY_FUNCTION__;
 
@@ -58,6 +48,22 @@ inline StringRef getTypeName() {
   return "UNKNOWN_TYPE";
 #endif
 }
+} // namespace detail
+
+/// We provide a function which tries to compute the (demangled) name of a type
+/// statically.
+///
+/// This routine may fail on some platforms or for particularly unusual types.
+/// Do not use it for anything other than logging and debugging aids. It isn't
+/// portable or dependendable in any real sense.
+///
+/// The returned StringRef will point into a static storage duration string.
+/// However, it may not be null terminated and may be some strangely aligned
+/// inner substring of a larger string.
+template <typename DesiredTypeName> inline StringRef getTypeName() {
+  static StringRef Name = detail::getTypeNameImpl<DesiredTypeName>();
+  return Name;
+}
 
 } // namespace llvm
 

[Mogball]

Thanks. I noticed this in debug builds too

[llvm-ci]

LLVM Buildbot has detected a new failure on builder llvm-clang-x86_64-win-fast running on as-builder-3 while building llvm at step 7 "test-build-unified-tree-check-llvm-unit".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/2/builds/13172

Here is the relevant piece of the build log for the reference

Step 7 (test-build-unified-tree-check-llvm-unit) failure: test (failure)
******************** TEST 'LLVM-Unit :: IR/./IRTests.exe/0/99' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\build\unittests\IR\.\IRTests.exe-LLVM-Unit-1140-0-99.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=99 GTEST_SHARD_INDEX=0 C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\build\unittests\IR\.\IRTests.exe
--

Script:
--
C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\build\unittests\IR\.\IRTests.exe --gtest_filter=LoopCallbacksTest.InstrumentedInvalidatingPasses
--
unknown file: error: 
Unexpected mock function call - returning directly.
    Function call: runAfterPassInvalidated("", @000000461D18D4B0 80-byte object <C8-D4 18-1D 46-00 00-00 02-00 00-00 01-00 00-00 00-00 00-00 01-00 00-00 70-B0 C6-63 F6-7F 00-00 00-00 00-00 00-00 00-00 F0-D4 18-1D 46-00 00-00 02-00 00-00 00-00 00-00 00-00 00-00 01-02 00-00 10-D7 18-1D 46-00 00-00 60-D8 18-1D 46-00 00-00>)
Google Mock tried the following 2 expectations, but none matched:

C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\llvm-project\llvm\unittests\IR\PassBuilderCallbacksTest.cpp(910): tried expectation #0: EXPECT_CALL(CallbacksHandle, runAfterPassInvalidated(HasNameRegex("MockPassHandle"), _))...
  Expected arg #0: has name regex (Name: "MockPassHandle")
           Actual: "", has name ''
         Expected: to be called once
           Actual: never called - unsatisfied and active
C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\llvm-project\llvm\unittests\IR\PassBuilderCallbacksTest.cpp(913): tried expectation #1: EXPECT_CALL(CallbacksHandle, runAfterPassInvalidated(HasNameRegex("^PassManager"), _))...
  Expected arg #0: has name regex (Name: "^PassManager")
           Actual: "", has name ''
         Expected: to be called once
           Actual: never called - unsatisfied and active

unknown file: error: 
Unexpected mock function call - returning directly.
    Function call: runAfterPassInvalidated("", @000000461D18D860 80-byte object <78-D8 18-1D 46-00 00-00 02-00 00-00 01-00 00-00 00-00 00-00 01-00 00-00 70-B0 C6-63 F6-7F 00-00 B8-D7 18-1D 46-00 00-00 A0-D8 18-1D 46-00 00-00 02-00 00-00 00-00 00-00 00-00 00-00 01-02 00-00 C0-A6 B9-3A 22-02 00-00 70-52 BA-3A 22-02 00-00>)
Google Mock tried the following 2 expectations, but none matched:

C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\llvm-project\llvm\unittests\IR\PassBuilderCallbacksTest.cpp(910): tried expectation #0: EXPECT_CALL(CallbacksHandle, runAfterPassInvalidated(HasNameRegex("MockPassHandle"), _))...
  Expected arg #0: has name regex (Name: "MockPassHandle")
           Actual: "", has name ''
         Expected: to be called once
           Actual: never called - unsatisfied and active
C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\llvm-project\llvm\unittests\IR\PassBuilderCallbacksTest.cpp(913): tried expectation #1: EXPECT_CALL(CallbacksHandle, runAfterPassInvalidated(HasNameRegex("^PassManager"), _))...
  Expected arg #0: has name regex (Name: "^PassManager")
           Actual: "", has name ''
         Expected: to be called once
           Actual: never called - unsatisfied and active

C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\llvm-project\llvm\unittests\IR\PassBuilderCallbacksTest.cpp(907): error: Actual function call count doesn't match EXPECT_CALL(CallbacksHandle, runAfterAnalysis(HasNameRegex("MockAnalysisHandle"), HasName("loop")))...
         Expected: to be called once
           Actual: never called - unsatisfied and active

C:\buildbot\as-builder-3\llvm-clang-x86_64-win-fast\llvm-project\llvm\unittests\IR\PassBuilderCallbacksTest.cpp(903): error: Actual function call count doesn't match EXPECT_CALL(CallbacksHandle, runBeforeAnalysis(HasNameRegex("MockAnalysisHandle"), HasName("loop")))...
         Expected: to be called once
           Actual: never called - unsatisfied and active

...