[Mlir-commits] [mlir] [mlir][emitc] Support scalar MemRef types (PR #92684)

[Gil Rapaport]

aniragil wrote:

>I'm not convinced that this is the canonical way to handle rank-0 memrefs. For example, when you have a rank-0 memref as function argument and then the function body writes into it, you cannot turn the argument into a scalar.

Good catch! Function arguments completely slipped my mind. We can perhaps temporarily exclude their support using the signature conversion mechanisms, but better have a complete design first. For now we can use rank-1 memrefs in the scf lowering pass.

While passing variables by reference  in C requires conversion to pointer/array, C++ has native support for that. Both representations differ from the way C/C++ programmers define and use scalars within functions. It would be good to emit natural C/C++ code where possible. There are also other cases where different C-variants have distinct natural constructs, e.g. `TupleType` (lowered to C++'s `std::tuple`, but requires a `struct` in C), `VectorType` (OpenCL-C, CUDA, GCC vector extensions) and address spaces (OpenCL-C, CUDA).

> There are alternative ways to lower this (e.g. promoting rank-0 memrefs to rank-1, or turning rank-0 memrefs into scalars to pointers)

Modeling variables consistently using `!emitc.ptr` was actually proposed as "Solution 1" in the variables [RFC](https://discourse.llvm.org/t/rfc-separate-variables-from-ssa-values-in-emitc/75224). This patch aimed to follow [simons suggestion](https://discourse.llvm.org/t/rfc-separate-variables-from-ssa-values-in-emitc/75224/2) which suggests natural C variable syntax.

> Converting rank-0 memrefs to scalars sounds like a transform that is not specific to emitc, so I'm more in favor of having this as a separate transform (in the memref dialect) instead if merging it into the memref-to-emitc conversion pass.

Doing Mem2Reg/SROA within the memref dialect where possible is indeed desired and not limited to rank-0 memrefs. Regardless, rank-0 memrefs model the concept of scalar variables which also lowers naturally and directly to llvm IR, e.g. the following

```mlir
memref.global @scalar : memref<f32> = dense<1.0>
memref.global @array : memref<1xf32> = dense<1.0>
```

gets lowered to

```mlir
  llvm.mlir.global external @scalar(1.000000e+00 : f32) {addr_space = 0 : i32} : f32
  llvm.mlir.global external @array(dense<1.000000e+00> : tensor<1xf32>) {addr_space = 0 : i32} : !llvm.array<1 x f32>
````

which translates to

```llvm
@scalar = global float 1.000000e+00
@array = global [1 x float] [float 1.000000e+00]
```


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