This is an archive of the discontinued LLVM Phabricator instance.

Add support for versioning properties in MLIR bytecode
ClosedPublic

Authored by mfrancio on Jul 14 2023, 2:59 PM.

Details

Summary

[mlir] Add support for custom readProperties/writeProperties methods.

Currently, operations that opt-in to adopt properties will see auto-generated readProperties/writeProperties methods to emit and parse bytecode. If a dialects opts in to use usePropertiesForAttributes, those definitions will be generated for the current definition of the op without the possibility to handle attribute versioning.

The patch adds the capability for an operation to define its own read/write methods for the encoding of properties so that versioned operations can handle upgrading properties encodings.

In addition to this, the patch adds an example showing versioning on NamedProperties through the dialect version API exposed by the reader.

Diff Detail

Event Timeline

mfrancio created this revision.Jul 14 2023, 2:59 PM
Herald added a project: Restricted Project. · View Herald Transcript
mfrancio requested review of this revision.Jul 14 2023, 2:59 PM
mehdi_amini added inline comments.Jul 14 2023, 6:36 PM
mlir/lib/Bytecode/Reader/BytecodeReader.cpp
1072 ↗(On Diff #540569)

I am not fond of having this weird transactional way of changing the state of the reader temporarily to carry this information.

Here is a patch

that add a map that would allow clients to get a version for any dialect by name: can we use this kind of mechanism instead?

mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
1545

I think we should split the logic for adding bytecode in another method and keep the control flow simple.

Can you outline the code from line 1337 to the end?

(I think this method has outgrown what's reasonable anyway)

mfrancio updated this revision to Diff 540726.Jul 15 2023, 12:19 PM
  • Refactors the way the dialect version is exposed to the reader
  • Outlines readProperties/writeProperties methods generation into a new method of OpEmitter
mfrancio marked 2 inline comments as done.Jul 15 2023, 12:29 PM
mfrancio added inline comments.
mlir/lib/Bytecode/Reader/BytecodeReader.cpp
1072 ↗(On Diff #540569)

Makes sense to do this - i leveraged it to refactor the dialect reader, which now holds a reference of the map since construction.

BTW, does it make sense anymore now to have readAttribute/readType taking a version?
https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Bytecode/BytecodeImplementation.h#L301

I feel we should consolidate the two methods.

I will also use the same strategy for https://reviews.llvm.org/D153383, which simplifies things a bit.

BTW, does it make sense anymore now to have readAttribute/readType taking a version?

https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Bytecode/BytecodeImplementation.h#L301

Not if already accessible on reader no.

I'm not sure what consolidating would mean though, I think we need a separate read for attribute and type given they only differ in return (c++) type

mfrancio marked an inline comment as done.Jul 17 2023, 4:48 PM

BTW, does it make sense anymore now to have readAttribute/readType taking a version?

https://github.com/llvm/llvm-project/blob/main/mlir/include/mlir/Bytecode/BytecodeImplementation.h#L301

Not if already accessible on reader no.

I'm not sure what consolidating would mean though, I think we need a separate read for attribute and type given they only differ in return (c++) type

Exactly, once the reader have access to the version there is no need of having a specific API with a version passed as an argument.

mfrancio updated this revision to Diff 545271.Jul 28 2023, 1:57 PM

Edit commit message

mfrancio edited the summary of this revision. (Show Details)Jul 28 2023, 1:58 PM
mehdi_amini accepted this revision.Jul 28 2023, 5:03 PM
This revision is now accepted and ready to land.Jul 28 2023, 5:03 PM
This revision was automatically updated to reflect the committed changes.