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

[Kirill Chibisov]

kchibisov wrote:

>consider (*(wrong_struct*)pointer_to_int).field_out_of_bounds).

Wouldn't it break because of the `deref` in the chain when talking about `mlir` semantics? Like `deref` would force a load of `struct` those copy and member will operate on the loaded copy?

Though, I can remove this rule.

> it would be illegal to move the first load from a beyond the second store to a. The side effects is the MLIR modelling for those semantics. To prove that expressions could be merged requires proving first that one of them can be moved next to the other without violating side effect order (e.g. read after write).

Just to ensure, are you talking about moving of the `load` instructions itself and not about anything related to `CExpression`? Since I'd assume that what you're talking about is speculative change of order of operations here. If that's the case, isn't `MemoryEffects` is what it's used for? The `HasSideEffects` from my point of view is a hand rolled concept to better model `C` side effects. From the `MLIR` perspective, the `MLIR` interface should be used instead.

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