Lowering class & struct down to MLIR standard dialects

[keryell]

I have started lowering the class & struct product types down to MLIR standard dialects by relying on the fundamental MLIR product type (built-in tuple) and that works up to the point that they meet some memory. After some debug, it looks like memref and tuple cannot compose. 🤯 😢
Some past discussion context: https://discourse.llvm.org/t/why-cant-i-have-memref-tuple-i32-i32/1853/6 https://discourse.llvm.org/t/memref-type-and-data-layout/2116
I thought there would be some kind of support for data layout through MemRefElementTypeInterface but this work only user-defined types. 😦
This is a basic example where we need standard dialect support for basic higher-level language support as suggested by @joker-eph in a presentation at the last LLVM Dev Mtg.
It is unclear how to move on to integrate better CIR with MLIR standard dialects.
Some possible actions I am thinking of:

• someone has a brilliant idea 😄
• give up and focus on direct CIR → LLVMIR translation;
• just focus on having CIR to work well with MLIR standard transformations and analysis;
• translate any struct to an int of the struct size and generate memory cast operations and bit-field extraction/insertion all over the place to emulate the tuple access;
• add better support for tuple in MLIR;
• introduce a new memory-friendly MLIR tuple-like type;
• keep cir.struct just for that;
• go directly to llvm.struct just for that.
  How does it work with Flang since F90 introduced derived data types?

[lanza]

FWIW, our goal for the cir dialect is to eventually get closer in functionality to the MLIR dialects. e.g. to put it simply we would heuristically like something similar to a cir.affine at some point. This would line up with your #2 and #3 if I understand correctly.

[bcardosolopes]

I like @ChuanqiXu9 idea of throughMLIR starting of on top of LLVM dialect and getting the pieces moved incrementally to standard dialect. Seems like all the points on improving MLIR with tuple and whatnots are good path too and can be done in parallel.

translate any struct to an int of the struct size and generate memory cast operations and bit-field extraction/insertion all over the place to emulate the tuple access;

If this allows you to make progress, I'd go for it as well!

How does it work with Flang since F90 introduced derived data types?

There was an interesting experiment report as part of https://sc24.conference-program.com/presentation/?id=ws_llvmf103&sess=sess754, where the author played with FIR to standard dialects (versus direct to LLVM, which seems to be the default?). I bet he might be able to provide you some extra insights.