This is an archive of the discontinued LLVM Phabricator instance.

[mlir:vscode] Add support for viewing and editing a bytecode file as .mlir
ClosedPublic

Authored by rriddle on Aug 30 2022, 12:59 PM.

Details

Summary

This commit adds support for interacting with a (valid) bytecode file in the same
way as .mlir. This allows editing, using all of the traditional LSP features, etc. but
still using bytecode as the on-disk serialization format. Loading a bytecode file this
way will fail if the bytecode is invalid, and saving will fail if the edited .mlir is invalid.

Diff Detail

Event Timeline

rriddle created this revision.Aug 30 2022, 12:59 PM
rriddle requested review of this revision.Aug 30 2022, 12:59 PM
jpienaar accepted this revision.Aug 31 2022, 5:06 PM

Nice! The typescript I peripherally followed only. I was expecting this to be worse. Is period in schema the preferred form? (I saw some with colons but wasn't sure what is the defacto reference)

mlir/lib/Tools/mlir-lsp-server/MLIRServer.cpp
320

I thought ModuleOp was intended to not be required here?

612

Was this just discovered with this change or why is changed here along with bytecode?

1279

Could we avoid saving in this case to not make it accidentally lossy viewing?

This revision is now accepted and ready to land.Aug 31 2022, 5:06 PM
rriddle updated this revision to Diff 457730.Sep 2 2022, 4:25 PM
rriddle marked 3 inline comments as done.

Nice! The typescript I peripherally followed only. I was expecting this to be worse. Is period in schema the preferred form? (I saw some with colons but wasn't sure what is the defacto reference)

period/dash/etc are all fine, colon separates the scheme from the rest of the content.

mlir/lib/Tools/mlir-lsp-server/MLIRServer.cpp
320

Thanks for the comment here. It was in my head that we need this, but the real constraint we have for bytecode right now is single op, restructured this to just block loading/saving on that (with TODOs that we can fix that if/when necessary).

612

Unnecessary now.

1279

We can't even detect this right now. I think we should have some mechanism for parsing in unknown external resources opaquely, which would allow for us to round trip. The producer case I'm not sure how we want to handle. If the user saves, technically the producer of the bytecode will be different. It will also be interesting in how the support here interacts with versioning and auto-upgrade whenever that happens.

This revision was landed with ongoing or failed builds.Sep 2 2022, 6:16 PM
This revision was automatically updated to reflect the committed changes.