[Mlir-commits] [mlir] [mlir][python] remove various caching mechanisms (PR #70831)

[Oleksandr Alex Zinenko]

================
@@ -57,15 +57,18 @@ void PyGlobals::loadDialectModule(llvm::StringRef dialectNamespace) {
     break;
   }
 
+  if (loaded.is_none())
+    return false;
   // Note: Iterator cannot be shared from prior to loading, since re-entrancy
   // may have occurred, which may do anything.
-  loadedDialectModulesCache.insert(dialectNamespace);
+  loadedDialectModules.insert(dialectNamespace);
+  return true;
----------------
ftynse wrote:

Thanks for the explanation!

> That's true but there's only one (under reasonable circumstances) that could possibly actually trigger a load that doesn't succeed (as far as I can imagine)

If we have a type/attr from an unregisterd/unloadable dialect, I believe we can still process that opaquely and have a python object representing that type/attr. Wouldn't obtaining such an object trigger caster lookup that always lead to repeated module searches?

> In the absense of the added custom_dialect.custom.py, it's exactly as you say (the lookup happens over and over) but with the addition of that module it only happens once.

I suppose creating ops from an unloaded/unregistered dialect isn't very common, so it's not critical to improve that, but still nice to have.

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