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

[llvmlistbot at llvm.org]

Jimmy2027 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?

If I understand correctly at the memref level, it is expected to model the constness with side effects and ops (memref.global constant). I'm not sure if something like a const attr to the memref type breaks its philosophy...

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

Yeah maybe this is the safest way forward for this PR, though I still can't think of any meaningful example where casting away the constness is actually needed... 

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

yup I agree, that would be the nicest solution. The case I'm currently working with is actually obvious since the memref comes from a const global


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