This is an archive of the discontinued LLVM Phabricator instance.

Refactor OperationName to use virtual tables for dispatch (NFC)
ClosedPublic

Authored by mehdi_amini on Jan 11 2023, 6:02 AM.

Details

Summary

This streamlines the implementation and makes it so that the virtual tables are in the binary instead of dynamically assembled during initialization.
The dynamic allocation size of op registration is also smaller with this
change.

Diff Detail

Event Timeline

mehdi_amini created this revision.Jan 11 2023, 6:02 AM
mehdi_amini requested review of this revision.Jan 11 2023, 6:02 AM

Make OperationName::Impl itself having a vtable instead of having an extra level of indirection

rriddle accepted this revision.Jan 12 2023, 10:59 AM
rriddle added inline comments.
mlir/unittests/Interfaces/InferTypeOpInterfaceTest.cpp
39

Debugging?

This revision is now accepted and ready to land.Jan 12 2023, 10:59 AM

Some more cleanup, moved many APIs from RegisteredOperationName to OperationName since they are just dynamic dispatch and the UnregisteredModel implementation does the right thing.

mehdi_amini added inline comments.Jan 12 2023, 2:25 PM
mlir/unittests/Interfaces/InferTypeOpInterfaceTest.cpp
39

Yes, but I figured it makes sense to keep it in the unit-test: it is mildly better than a bad segfault on the next line.

mehdi_amini marked an inline comment as done.Jan 12 2023, 2:26 PM
This revision was landed with ongoing or failed builds.Jan 13 2023, 5:27 PM
This revision was automatically updated to reflect the committed changes.

Hi @mehdi_amini, this patch is causing MSVC-compiled mlir-opt to crash at runtime with the following stack trace. Could you revert the patch for now to get the build working again please?

Exception Code: 0xC0000005

 #0 0x00007ff6a30cf153 llvm::function_ref<(class mlir::OpAsmParser &, struct mlir::OperationState &)>::callback_fn<class mlir::ParseResult (__cdecl *)(class mlir::OpAsmParser &, struct mlir::OperationState &)>(__int64, class mlir::OpAsmParser &, struct mlir::OperationState &) llvm-project\llvm\include\llvm\ADT\STLFunctionalExtras.h:45:0

 #1 0x00007ff6a85d82aa llvm::function_ref<(class mlir::OpAsmParser &, struct mlir::OperationState &)>::operator()(class mlir::OpAsmParser &, struct mlir::OperationState &) const llvm-project\llvm\include\llvm\ADT\STLFunctionalExtras.h:68:0

 #2 0x00007ff6a8a27468 `anonymous namespace'::CustomOpAsmParser::parseOperation llvm-project\mlir\lib\AsmParser\Parser.cpp:1439:0

 #3 0x00007ff6a8a207e4 `anonymous namespace'::OperationParser::parseCustomOperation llvm-project\mlir\lib\AsmParser\Parser.cpp:1934:0

 #4 0x00007ff6a8a1ce68 `anonymous namespace'::OperationParser::parseOperation llvm-project\mlir\lib\AsmParser\Parser.cpp:1143:0

 #5 0x00007ff6a8a2b366 `anonymous namespace'::TopLevelOperationParser::parse llvm-project\mlir\lib\AsmParser\Parser.cpp:2611:0

 ...

I'm not sure why the pre-merge checks didn't catch this. Perhaps they're not running, since I don't see build results here.

Sorry for the breakage! Is Exception Code: 0xC0000005 a segfault?
Any chance you could get a debug build symbolized backtrace here?

I see you posted a symbolized trace here, sorry I was looking directly at the logs on the bot :)

I think I should be able to re-land this with a fix soon

No worries, thanks for reverting! As I understand, Exception Code: 0xC0000005 does mean a segfault.