[Mlir-commits] [mlir] Handled UnrealizedConversionCast for C code generation and validated tests (PR #160159)
Simon Camphausen
llvmlistbot at llvm.org
Sun Sep 28 01:42:00 PDT 2025
simon-camp wrote:
Hi @LekkalaSravya3, thanks for the contribution. Wouldn't we need to decay the outer most array dimension to pointer, i.e. `array<2x3xi32> -> ptr<array<3xi32>>`?
Additionally I also think this should be fixed in the lowering of `memref.alloc` and the type conversion. Though I haven't thought about all details.
> Thanks for reporting and addressing this issue. I'm not entirely sure though that the solution should be adding support for unrealized casts in the translator. As we end up with the unrealized type conversion, it seems our type conversion in `MemRefToEmitC` may not cover this case. I wonder if the solution you propose (generating a cast to a pointer to an array and supporting it in `emitc.subscript`) can be implemented as part of lowering so that we don't get the unrealized cast in the first place?
I think that is the correct place to fix this. Adding support for `ptr(array)` is mostly involving updating the emitter. IIRC this type cannot be simply emitted left to right. so we would need a bit of book keeping in `emitType`. I think I have some python prototype lying around when/where to add parentheses into the emitted type.
Do you suggest that subscript will support `emitc.subscript %a[%c3, %c1] : ptr<array<2xi32>> -> i32` directly? That vastly simplifies the problem then I think.
If we would need to split between pointer and array indexing it will get complicated, as the outer subscript won't be able to get materialized (it's emitted as an assignment to array type). Otherwise we would need to wrap all this into an expression with a combination of subscripts and loads.
https://github.com/llvm/llvm-project/pull/160159
More information about the Mlir-commits
mailing list