[Mlir-commits] [mlir] [mlir][emitc] Relax `hasSideEffect` rules for Var/Member (PR #145011)

[Kirill Chibisov]

kchibisov wrote:

>Actually I do mean that in the CExpression/emitc.expression aspect, as both the form-expressions pass and the translator rely on the hasSideEffect() API to avoid merging/inlining expressions which are not safe to move speculatively for whatever reason (emitc.expression's only purpose is to provide better-looking C code).
We should definitely refine form-expression's merge logic to merge load and stores where possible, and we should use [MLIR's existing side effect interfaces](https://mlir.llvm.org/docs/Rationale/SideEffectsAndSpeculation/) for that, but we'd still need to make sure we're not changing memory semantics when moving ops.

But in that case, it doesn't matter, since `load` is basically a reference to address being read, so you can not end with change of order if you do so, since even if the data changes, the load operation itself remains the same, since it refers the memory location on stack rather than the name semantically speaking. It could be problematic, if you end up with the extra `bind` somehow that got moved further, and the load is done through the bind, but if we assume that `writes` remain the same (which they will), I don't see how any of that would affect anything?

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