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

Théo Degioanni llvmlistbot at llvm.org
Sat Apr 20 07:10:27 PDT 2024


Moxinilian wrote:

> A value is defined by an operation but used in a region nested beneath another operation in the same region. This is an implicit capture, and it actually has the same semantics as the case above: it can be considered “captured” as an implicit operand by the operation in the same region as where it is defined (point of evaluation), as if the operation was isolated. Without more information you can’t infer anything about the region execution here.

Here we are modelling effects that are not embedded in the value semantics, typically `load %x` and `store %x`. The definition of dominance you mention is not general enough to model this. 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), because the value can still be modified after the region declaration:

```mlir
store %ptr
%promise = async {
    load %ptr
}
store %ptr
evaluate %promise
```

The value pointed at by the pointer has not been captured and cannot be, precisely because the region does not own it.

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. In the example above, we would say that the second store dominates the load in the region. 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.

The reason people have been saying that the notion of dominance verified in the MLIR verifiers is more "syntactic" is because it matches the natural dominance observed in the syntax without modelling this more precise, other relationship also called dominance. This other relationship (or a safe approximation of it) is the one we need in mem2reg.

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


More information about the Mlir-commits mailing list