[Mlir-commits] [mlir] [MLIR] Add single definition multiple regions for mem2reg (PR #89107)

[Mehdi Amini]

joker-eph wrote:

> Here we are modelling effects that are not embedded in the value semantics, typically load %x and store %x.

I understand that quite well, however:

> The definition of dominance you mention is not general enough to model this. 

Can you please refer to the existing literature and provide pointer to any definition of what you want to discuss? 
I can't follow you because it seems to me that you're trying to mix-and-match things that don't fit together: I'm not the one who brought dominance in the discussion here!!


> There is no capture when a store happens outside of a region and a load inside the region (except for the pointer of course but that does not model what we are after),

I believe the pointer is exactly what we're after here actually. The region capturing the pointer means the pointer escape, and that implies that without more information you can't know when the load happens (the "pointer escaping" is what makes it possible that the region can be executed concurrently for example).


> The value pointed at by the pointer has not been captured and cannot be

Sure... but I don't quite see how it relates to the discussion about the dominance?
The memory state is something that changes potentially with every single operation, I really can't follow how you're trying to tie in the memory state to dominance!

> When we say dominance we really do mean "op A dominates op B" if and only if "for all control-flow paths reaching op B, this path goes through op A", in the very academic sense, which depends on execution properties such as deferred execution. 

This is exactly the definition I have been using (I mean: I sent the link above in the discussion...).
This is the basis under which I explained above how the semantics works in MLIR.

> In the example above, we would say that the second store dominates the load in the region

I don't think so: it highly depends on the semantics of async here. There is no dominance if there is concurrent execution here I believe.

And back to MLIR semantics, in your example:

- the first store properly dominates the the `async` op, and the region nested within the `async` op.
- the async op properly dominates the second store.
- the only dominance property associated with the region nested within the async op is that all operations dominating the async are also dominating all the operations here. There is no dominance relationship between the load and the second store. As I mentioned before, an interface like RegionOpInterface **can** provide this extra information, for example for something like `scf.execute_region`, but without interfaces you just can't infer anything (and "asynchronicity" just does not allow to infer anything in terms of dominance).


>  Perhaps this is not the same semantics as what has been used in MLIR for the word "dominance", but at least this is what we need. I think we are only arguing about terms here.

Terminology is key though: everything I've done here is insisting that you're a bit more consistent with it (also because I had concerned with the angle presented by the talk last year on this point).




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