[Mlir-commits] [mlir] Handled UnrealizedConversionCast for C code generation and validated tests (PR #160159)

[Gil Rapaport]

aniragil wrote:

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

Not sure I follow: operators `*` and `[]` have the same (top) precedence and left-to-right associativity, right?
 
> 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.

Yes, as `emitc.subscript` already supports pointers but forces a single index in `verify()` we could arguably generalize it to support (element-type-rank + 1) indices.

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

Right, the `emitc.apply *` op predates the `lvalue` changes it doesn't return an `lvalue` but also loads the value (and is therefore marked as having a side effect). Since the pointer de-referencing would be done first, yielding an array, we'll need to add the `emitc.apply` op to the "deferred emission" mechanism when the de-referenced type is an array to solve the materialization problem and mark the op as not having a side effect in that case.

> Otherwise we would need to wrap all this into an expression with a combination of subscripts and loads.

Right, as an alternative to adding `emitc.apply` to "deferred emission" (by `load` you mean the user of the subscript, right?).
The `emitc.apply *` side effect may still need to be refined so that the expression can be inline.

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