This is an archive of the discontinued LLVM Phabricator instance.

[mlir][llvm] Handle invoke op branching to block with its result as an argument
ClosedPublic

Authored by victor-eds on Apr 14 2023, 1:55 AM.

Details

Summary

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.

Diff Detail

Event Timeline

victor-eds created this revision.Apr 14 2023, 1:55 AM
Herald added a reviewer: dcaballe. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
victor-eds requested review of this revision.Apr 14 2023, 1:55 AM

Thank you! I think this approach makes the most sense.

For reference for others, this was previously discussed here: https://discourse.llvm.org/t/improvements-to-llvm-dialect-exception-related-operations/69503

mlir/lib/Target/LLVMIR/ModuleImport.cpp
1299

Please spell out the autos here and below. MLIR generally only uses auto when the type already appears on the right hand side or for difficult to spell out names (iterators, lambdas etc)

mlir/test/Target/LLVMIR/Import/basic.ll
97

It seems this has sadly not been done consistently in this file :(, but could we use FileCheck variable for the basic block names here?

97

Address comments

victor-eds marked 3 inline comments as done.Apr 14 2023, 3:00 AM

Thanks for the quick review! I've addressed your comments already.

zero9178 accepted this revision.Apr 14 2023, 3:13 AM

LGTM!
Please wait a day or so in case other reviewers have anything to add

This revision is now accepted and ready to land.Apr 14 2023, 3:13 AM
gysit accepted this revision.Apr 14 2023, 3:51 AM

LGTM, feel free to move the exception related tests into a separate test file, e.g. exception.ll, now that you are extending test coverage and functionality!

LGTM, feel free to move the exception related tests into a separate test file, e.g. exception.ll, now that you are extending test coverage and functionality!

Good point! I'll do it in a further PR. Thanks!