[Mlir-commits] [flang] [mlir] [MLIR][OpenMP] Automate operand structure definition (PR #99508)

[Jeff Niu]

================
@@ -408,17 +408,26 @@ class ElementsAttrBase<Pred condition, string summary> :
   let storageType = [{ ::mlir::ElementsAttr }];
   let returnType = [{ ::mlir::ElementsAttr }];
   let convertFromStorage = "$_self";
+
+  // The underlying C++ value type of each element.
+  string elementReturnType = ?;
----------------
Mogball wrote:

> in a way that is useful for us

This is kind of the crux of the issue. There is a kind of layering inversion here: only the OMP tablegen backend makes use of this information, yet the onus is on the main tablegen definitions to provide this information. No other dialects will realistically ever have to provide these definitions, and it's not clear to them why these are useful if they aren't using OMP.

I don't think there's a way forward for adding this kind of metadata to ODS proper if there is no conceivable use outside of OMP. Since the information has to be specified manually for ODS definitions to be used with OMP, would it be much worse to have a centralized mapping of `Attr -> C++ representation`?

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