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

[Simon Camphausen]

simon-camp wrote:

I'm trying to summarize the discussion so far to highlight questions I have right now (much of this was also already written down in the RFC):

- add new type that designates [modifiable](https://en.cppreference.com/w/c/language/value_category#Modifiable_lvalue_expressions) values (currently `lvalue` possibly renamed to `mlvalue` to distinguish this from array variables)
- EmitC operations work on non-lvalues unless explicitly defined otherwise
- Conversion to non lvalue types is done explicitly through a new op (currently `lvalue_to_rvalue`) which is directly emitted as an assignment to an anonymous variable.
  - (Maybe we should rename this to lvalue_load or something as the name lvalue conversion is connotated with implicit behaviour for me)
- ops working with the new type
  - lhs operand of the assign op
  - operand of the apply op if it's an `&` 
  - the result of the subscript op
  - result of the apply op if it's an `*`
  - result of the variable op
    - unless it's an array, as arrays are not assignable. Additionally there would be no way to work this such a value as the conversion op wouldn't work either [^1]
  - result of the get_global op
- adding traits/effects to ops
  - lvalue_to_rvalue has a read effect
  - assign has a write effect on lhs
  - variable has alloc effect
    - we should add `AutomaticAllocationScope`to all op having regions (func, for, if branches)

Somewhat related, we have a few ops (subscript, get_global) that are specifically handled in the emitter to not immediately create variables. Can we categorize these as exactly those ops returning mlvalues except for the variable op?

[^1] I don't know how to lower the [memref-to-emitc](https://github.com/llvm/llvm-project/blob/main/mlir/test/Conversion/MemRefToEmitC/memref-to-emitc.mlir) if we don't distinguish modifiable and array variables.

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