[Mlir-commits] [mlir] [mlir][IR] Add builtin `TokenType` (PR #195640)

[Mehdi Amini]

================
@@ -0,0 +1,104 @@
+# Tokens
+
+[TOC]
+
+## Overview
+
+Intuitively, a *token* value is a pointer to an operation (via an OpResult)
+or a pointer to a region (via an entry block argument). A token cannot be
+forwarded: a token def-use chain cannot be obscured by ops with forwarding
+semantics such as `arith.select` or `cf.br`. This allows you to always walk
+back from a use and say "this token came from *that* specific op". 
+
+A token is an SSA value that has the builtin token type. The token type is
+parameterless, opaque and prints as `token`. A token carries no runtime data.
+Apart from the structural contract below, tokens are like any other SSA values.
+
+## Design Rationale
+
+The token type allows operations to refer to another operation without a new
+parallel def-use system for operations. The existing def-use machinery for SSA
+values can be reused. Moreover, no changes were needed for the generic op
+syntax, the bytecode infrastructure and core C++ APIs around `Operation`.
+
+As with regular use-def chains, a token def-use chain is unidirectional. A
+token use points to the token's definition. (But not the other way around.)
+Transformations can remove the use of a token without having to touch or
+inspect the definition of the token. (Whether such a transformation is correct
+depends on the semantics of the token-producing and token-consuming ops.)
----------------
joker-eph wrote:

> I wrote this with the tf_executor.NextIteration.Sink example in mind, which has extra invariants, in addition to the https://github.com/llvm/llvm-project/pull/195640#discussion_r3225253970: it assumes a 1:1 mapping between source/sink ops.

This 1:1 isn't something we can provide with the token type. We should describe what the token type provides, and how we can manipulate it. So: can we DCE a token use that does not have side-effects?

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