================
@@ -502,6 +502,15 @@ def CIR_RecordType : CIR_Type<"Record", "record",
void complete(llvm::ArrayRef<mlir::Type> members, bool packed,
bool isPadded);
+
+ // Utilities for lazily computing and cacheing data layout info.
+ // FIXME: currently opaque because there's a cycle if CIRTypes.types include
+ // from CIRAttrs.h. The implementation operates in terms of RecordLayoutAttr
+ // instead.
+ private:
+ mutable mlir::Attribute layoutInfo;
----------------
xlauko wrote:
> We do want such cache to be tied to the IR (as you pointed out) because
> different passes might be able to reuse/explore the information.
But at the moment it is not tied to IR at all. It lives only for the duration
of specific `StructType` instance, so it cannot survive across passes.
With the current representation, there's no need to store this as a member of
RecordType. You could achieve the same result with a getLayoutInfo function
that computes the layout when needed. This would likely be more efficient in
terms of both time and memory usage. For example returning just something like
foolowing class from the method, and probably better computing each element
only when needed:
```cpp
struct LayoutInfo {
unsigned size;
unsigned alignment;
bool padded;
// ...
};
```
By the way, while browsing the MLIR codebase, I didn't come across any
extraClassDeclaration that defines non-static data members. So having such a
member here feels a bit unexpected to me.
https://github.com/llvm/llvm-project/pull/136036
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
