aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/DAGDeltaAlgorithm.cpp
diff options
context:
space:
mode:
authorVictor Perez <victor.perez@codeplay.com>2023-04-14 09:54:38 +0100
committerVictor Perez <victor.perez@codeplay.com>2023-04-18 10:54:02 +0100
commitbe717f0a49d9591fec6574cb9b186be904a2d604 (patch)
tree6d2eca9f73def4570b3c5fd44d90042bc67a5bb2 /llvm/lib/Support/DAGDeltaAlgorithm.cpp
parent39ca70392b5ef9f68a20ab4c08d2fae45a49bf4e (diff)
downloadllvm-be717f0a49d9591fec6574cb9b186be904a2d604.zip
llvm-be717f0a49d9591fec6574cb9b186be904a2d604.tar.gz
llvm-be717f0a49d9591fec6574cb9b186be904a2d604.tar.bz2
[mlir][llvm] Handle invoke op branching to block with its result as an argument
In LLVM, having an invoke instruction branching to a block with a phi node receiving the invoke instruction result as an argument is perfectly legal. However, the translation of this construct to MLIR would result in an invoke with its result being used as a block argument to a successor, i.e., the operation result would be used in its definition. In order to fix this issue due to different IR structures (phi nodes vs block arguments), this construct is interpreted with an llvm.invoke operation branching to a dummy block having a single llvm.br operation passing the required block arguments (including the result of the llvm.invoke operation) to the actual successor block. Differential Revision: https://reviews.llvm.org/D148313
Diffstat (limited to 'llvm/lib/Support/DAGDeltaAlgorithm.cpp')
0 files changed, 0 insertions, 0 deletions