[Mlir-commits] [mlir] [mlir][EmitC] Model lvalues as a type in EmitC (PR #91475)

[Matthias Gehre]

mgehre-amd wrote:

> Thanks @simon-camp for getting the work done, thanks @aniragil and @mgehre-amd for reviewing and for the valuable discussions. This really pushes the dialect forward!
> 
> There is one thing we should agree on before this is merged. As the patch introduces breaking changes, @simon-camp and I discussed offline that this requires a PSA. An non-breaking intermediate solution would be to _relax_ the restriction on `emitc.variable` and to allow `EmitCType` as a result. This would mean to replace
> 
> ```mlir
> let results = (outs Res<AnyTypeOf<[EmitC_ArrayType, EmitC_LValueType]>, "",
> ```
> 
> with
> 
> ```mlir
> let results = (outs Res<AnyTypeOf<[EmitCType, EmitC_ArrayType, EmitC_LValueType]>, "",
> ```
> 
> while we ignore the changes regarding the memory effects. Furthermore, the modifications to `emitc.apply` would need to be rolled-back and instead an `emitc.dereference` ([en.cppreference.com/w/c/language/operator_member_access](https://en.cppreference.com/w/c/language/operator_member_access)) / `emitc.indirection` ([en.cppreference.com/w/cpp/language/operator_member_access](https://en.cppreference.com/w/cpp/language/operator_member_access)) and `emitc.address_of` should be introduced (which we probably want to do in a follow up anyway). With this, the `emitc.variable` as well as `emitc.apply` op could still be used as before but users can adapt to the new behavior before the result type of the `emitc.variable` op gets restricted and the `emitc.apply` op is removed. However, adopting to the behavior shouldn't be too hard, thus we tend to keep the effort low and just go with a PSA and before merging this in **x?** weeks. WDYT?

Fine for me.

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