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

[Matthias Springer 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; }
----------------
matthias-springer wrote:

I didn't follow this discussion for a while. Was there a reason why we decided to add an `isAddressable` property as opposed to having an `AddressableResource` / `UnaddressableResource`?

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