Lowering through MLIR standard dialects: class, struct, arrays and other issues

[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.

[keryell]

My current experiments are done in #1334.
It sounds even more complicated since arrays currently work by chance and a lot of things are not working, like pointers on arrays which are removed...

[keryell]

The presentation from LLVM Dev Meeting 2024 https://www.youtube.com/watch?v=Bt__BDQivxo "Making upstream MLIR more friendly to programming languages: current upstream limitations, the ptr dialect, and the road ahead"
Speaker: Mehdi Amini, Fabian Mora Cordero

[PikachuHyA]

hi @keryell, thank you for your work on the lowering process through MLIR.

As mentioned in #1411 , do you have any plans to support built-in functions (e.g., printf)? Alternatively, could you provide some suggestions on how to implement support for these functions within the ThroughMLIR path?

[keryell]

@PikachuHyA implementing printf is not on my top-priority since my goal is not to run Hello World 😄 but rather to program useful things on some weird but interesting piece of hardware.
But other contributors are welcome.