[flang-commits] [flang] [mlir] [RFC][mlir] Resource hierarchy for MLIR Side Effects. (PR #181229)

[Slava Zakharin via flang-commits]

================
@@ -95,39 +106,92 @@ class Resource {
     /// Return the unique identifier for the base resource class.
     static TypeID getResourceID() { return TypeID::get<DerivedResource>(); }
 
-    /// 'classof' used to support llvm style cast functionality.
+    /// 'classof' used to support llvm style cast functionality. Returns true
+    /// iff the resource is the same as or a descendant of this resource type
+    /// in the hierarchy (so isa/cast work for ancestor checks).
     static bool classof(const Resource *resource) {
-      return resource->getResourceID() == BaseT::getResourceID();
+      return resource->isSubresourceOf(BaseT::get());
     }
 
   protected:
-    Base() : BaseResource(BaseT::getResourceID()){};
+    Base() : BaseResource(BaseT::getResourceID()) {}
+    /// Constructor for use when this type is used as a parent (BaseResource);
+    /// allows the derived resource to pass its TypeID so the hierarchy is
+    /// correct.
+    Base(TypeID id) : BaseResource(id) {}
   };
 
   /// Return the unique identifier for the base resource class.
   TypeID getResourceID() const { return id; }
 
   /// Return a string name of the resource.
-  virtual StringRef getName() = 0;
+  virtual StringRef getName() const = 0;
+
+  /// Return the parent resource in the hierarchy, or nullptr for a root.
+  virtual Resource *getParent() const { return nullptr; }
+
+  /// Returns true if this resource is addressable (effects on it can alias
+  /// pointer-based memory). Default is true.
+  virtual bool isAddressable() const { return true; }
----------------
vzakhari wrote:

Thanks for looking at it again!

@joker-eph suggested making it a property of a resource that is orthogonal to the hierarchy [here](https://discourse.llvm.org/t/rfc-mlir-memory-region-hierarchy-for-mlir-side-effects/89811/4). Since I initially was thinking about the same [approach](https://github.com/llvm/llvm-project/pull/178291), I decided to do it this way. I do not really have a strong preference here.

Please also note that the property ended up not completely orthogonal to the hierarchy: I believe, for consistency, we must assert that an addressable resource cannot be a sub-resource of a non-addressable resource (I added extra verification code for that).

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