[Mlir-commits] [mlir] [mlir][emitc] Fix creating pointer from constant array (PR #162083)

[Gil Rapaport]

aniragil wrote:

This doesn't seem like an emitc-specific issue (i.e. any dialect wishing to model that property in their type system would have a problem doing local type conversions) so this might be worth a wider discussion, e.g. are memref's memory spaces the proper way to carry this information? should memrefs support the constant property directly?

At least in the short term I think the simplest solution is indeed to cast the constness away when lowering `get_global`. It actually reflects the semantic knowledge the memrefs carry (the array is constant at definition but we don't have such information at the users) and it should be fairly easy to implement.

In the long run, adding a `const` attribute to emitc.ptr (or even to any emitc type) could be useful if there's any user that lowers to emitc a dialect that actually maintains the constant property in its types. We could also try to deduce it for memrefs by writing some global analysis to decide which pointer is constant. For example, since C allows passing non-constant where a constant is required we could try to mark pointers by default as constant and only mark pointers as non-constant if they reach `emitc.assign` ops (arbitrary C code might be too difficult to analyze but scf+memref-based code would perhaps be simple enough).

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