commit 54749cedb82724b7ecadecd2101dbef836ff2093
author Ben Vanik <benvanik@google.com> Tue Mar 02 16:17:08 2021 -0800
committer Ben Vanik <ben.vanik@gmail.com> Thu Mar 11 12:13:48 2021 -0800
tree 74606f15ffed3899c3546ca02d68a6802a5a257e
parent 9467a90339b2f466d5a2666aca8e31b3f84906f5

Adding TiedOpInterface and wiring it through the Flow dialect.
This allows for results of operations to be tied back to their
operands in storage but not in time. This allows for in-place
operations to be defined on tensors that carry enough metadata
to be able to correctly form streams, materialize HAL
interfaces, and allocate buffers.

Example:
```mlir
%t = flow.dispatch @foo[...](%input) : (tensor<4xf32>) -> %input
```

This syntax also combines with the shape-carrying op interface
to make it possible to also indicate that an input and a result
share type and shape information:
```mlir
%t = flow.dispatch @foo[...](%input) : (tensor<?xf32>{%dim}) -> %input
```
which is effectively:
```mlir
%t = flow.dispatch @foo[...](%input) : (tensor<?xf32>{%dim}) -> tensor<?xf32>{%dim}
```
but with the extra bit that result 0 is tied to operand 0.

Here the result %t of the dispatch aliases the storage for %input,
making %input a read-write/mutable binding in the resulting HAL
executable. %t is a distinct SSA value from %input, though, and
represents the value of the storage backing %input after the
dispatch has completed. By keeping the SSA use-def chains correct
with respect to time they are still meaningful for analysi2As and
nothing at this level (and the beginning of the HAL transformations)
needs to perform alias analysis, while still giving us all of the
information required to induce aliasing during later allocation
passes.