[all-commits] [llvm/llvm-project] 0c789d: [mlir] Add support for operation-produced successo...

[zero9178 via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0c789db541c236abf47265331a2f2b0945aa7b93
      https://github.com/llvm/llvm-project/commit/0c789db541c236abf47265331a2f2b0945aa7b93
  Author: Markus Böck <markus.boeck02 at gmail.com>
  Date:   2022-04-08 (Fri, 08 Apr 2022)

  Changed paths:
    M flang/include/flang/Optimizer/Dialect/FIROps.td
    M flang/lib/Optimizer/Dialect/FIROps.cpp
    M mlir/include/mlir/IR/OperationSupport.h
    M mlir/include/mlir/Interfaces/ControlFlowInterfaces.h
    M mlir/include/mlir/Interfaces/ControlFlowInterfaces.td
    M mlir/lib/Analysis/AliasAnalysis/LocalAliasAnalysis.cpp
    M mlir/lib/Analysis/BufferViewFlowAnalysis.cpp
    M mlir/lib/Analysis/DataFlowAnalysis.cpp
    M mlir/lib/Dialect/Bufferization/Transforms/BufferDeallocation.cpp
    M mlir/lib/Dialect/ControlFlow/IR/ControlFlowOps.cpp
    M mlir/lib/Dialect/Func/Transforms/FuncConversions.cpp
    M mlir/lib/Dialect/LLVMIR/IR/LLVMDialect.cpp
    M mlir/lib/Dialect/Linalg/Transforms/Detensorize.cpp
    M mlir/lib/Dialect/SPIRV/IR/SPIRVOps.cpp
    M mlir/lib/Interfaces/ControlFlowInterfaces.cpp
    M mlir/lib/Target/LLVMIR/ModuleTranslation.cpp
    M mlir/lib/Transforms/Utils/RegionUtils.cpp
    M mlir/test/Transforms/sccp.mlir
    M mlir/test/lib/Dialect/Test/TestDialect.cpp
    M mlir/test/lib/Dialect/Test/TestOps.td

  Log Message:
  -----------
  [mlir] Add support for operation-produced successor arguments in BranchOpInterface

This patch revamps the BranchOpInterface a bit and allows a proper implementation of what was previously `getMutableSuccessorOperands` for operations, which internally produce arguments to some of the block arguments. A motivating example for this would be an invoke op with a error handling path:
```
invoke %function(%0)
  label ^success ^error(%1 : i32)

^error(%e: !error, %arg0 : i32):
  ...
```
The advantages of this are that any users of `BranchOpInterface` can still argue over remaining block argument operands (such as `%1` in the example above), as well as make use of the modifying capabilities to add more operands, erase an operand etc.

The way this patch implements that functionality is via a new class called `SuccessorOperands`, which is now returned by `getSuccessorOperands`. It basically contains an `unsigned` denoting how many operator produced operands exist, as well as a `MutableOperandRange`, which are the usual forwarded operands we are used to. The produced operands are assumed to the first few block arguments, followed by the forwarded operands afterwards. The role of `SuccessorOperands` is to provide various utility functions to modify and query the successor arguments from a `BranchOpInterface`.

Differential Revision: https://reviews.llvm.org/D123062