This is an archive of the discontinued LLVM Phabricator instance.

Update ODS variadic segments "magic" attributes to use native Properties
ClosedPublic

Authored by mehdi_amini on Jul 21 2023, 12:22 AM.

Details

Summary

The operand_segment_sizes and result_segment_sizes Attributes are now inlined
in the operation as native propertie. We continue to support building an
Attribute on the fly for getAttr("operand_segment_sizes") and setting the
property from an attribute with setAttr("operand_segment_sizes", attr).

A new bytecode version is introduced to support backward compatibility and
backdeployments.

Diff Detail

Event Timeline

mehdi_amini created this revision.Jul 21 2023, 12:22 AM
Herald added a project: Restricted Project. · View Herald Transcript
mehdi_amini requested review of this revision.Jul 21 2023, 12:22 AM
ftynse added a subscriber: ftynse.Jul 21 2023, 12:57 AM

Random question: how do you expect these to be set up from the C API? It feels like direct access would be preferable to constructing a magic-named attribute that is later decayed into a property.

Mogball accepted this revision.Jul 21 2023, 8:51 AM

Been waiting for this one. @ftynse I think C bindings could just be added for direct access to the arrays.

This revision is now accepted and ready to land.Jul 21 2023, 8:51 AM

Random question: how do you expect these to be set up from the C API? It feels like direct access would be preferable to constructing a magic-named attribute that is later decayed into a property.

I think your question applies generally to properties right? We should definitely take a closer look at how we want to plumb properties through the C API layer.
I'm struggling to see how to do something generic though: that is we can easily have per-op C building APIs, but a generic "createOperationByName" seems though?

jpienaar added inline comments.Jul 22 2023, 4:25 PM
mlir/include/mlir/Bytecode/BytecodeImplementation.h
84

expected

mlir/lib/Bytecode/Reader/BytecodeReader.cpp
801

Why pass by reference?

mlir/lib/IR/ODSSupport.cpp
50

While here, "size" for consistency

mlir/test/IR/traits.mlir
386

Mmm, so we lose ability to differentiate between unset and "should be none"?

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

Same as above

434

Does all of this need to be here?

455

Does this fix the number of segments more so than before? E.g., I think this could be changed after construction before.

mehdi_amini marked 4 inline comments as done.

Address comment and change the bytecode encoding for a sparse array

mlir/lib/Bytecode/Reader/BytecodeReader.cpp
801

I should do a const ref and comment it out. But this is constructed before we start parsing the bytecode and populate later.

mlir/test/IR/traits.mlir
386

Yes: this is always the case with properties: they have a default ctor. Since this isn't a parsing check but a verifier check we only know there is an int32_t[4] array here and we can look its content but we don't know if it's default constructed or not.

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

Yes: this really specifies the properties: it is an array of int32_t, with a specific size, and then all various way we will interact with the property.

455

You're correct that xxx_segment_sizes as an attribute could technically be changing its rank over time, but I'm not sure this matches any existing concept in ODS? Do you have something in mind?

rriddle accepted this revision.Jul 23 2023, 12:59 AM

One of the easy wins of properties. I also vaguely recall we had some docs that referenced the segment attributes, do those need to be updated?

mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
174–176

Please drop the trivial braces

I grepped for segment in our doc and didn't find anything, except for VariadicOfVariadic which has a custom segment attribute. And that makes me think that I should likely handle VariadicOfVariadic as well!

Mogball accepted this revision.Jul 23 2023, 9:16 AM
Mogball added inline comments.
mlir/include/mlir/Bytecode/BytecodeImplementation.h
195

This is an interesting API. It reads and writes an array with a known max size. It may be worth mentioning that.

Document readSparseArray and remove trivial braces

Rename the property member odsOperandSegmentSizes for consistency with our coding style.
For backward compatibility, it is exported as an attribute with the old name.

mehdi_amini marked an inline comment as done.Jul 24 2023, 10:38 AM

I grepped for segment in our doc and didn't find anything, except for VariadicOfVariadic which has a custom segment attribute. And that makes me think that I should likely handle VariadicOfVariadic as well!

Actually it is more involved here, I won't do it this time. Also it is runtime variable size I think, so it'd need to be a std::vector.

mehdi_amini marked an inline comment as done.Jul 24 2023, 10:38 AM
gysit added inline comments.Jul 26 2023, 8:50 AM
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
455

@mehdi_amini we get the following compiler warning when using this downstream (upstream there seems to be no warnings for some reason):

.../llvm-project/install/include/mlir/Dialect/LLVMIR/LLVMOps.h.inc:10805:36: warning: comparison between two arrays is deprecated; to compare array addresses, use unary '+' to decay operands to pointers [-Wdeprecated-array-compare]
        rhs.odsOperandSegmentSizes == this->odsOperandSegmentSizes &&

It seems like there is a comparison between to int32_t c-arrays in the generated code that probably should compare the content of the arrays and not there addresses? Would it make sense to switch to std::array?

mehdi_amini added inline comments.Jul 26 2023, 11:32 AM
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
455

Ah that's quite a bug!

I didn't think about std::array, but it will likely simplify a bunch of the code indeed (some calls to llvm::copy could be replaced by assignments I think) and make it safer. Feel free to send a patch, other I'll try to do it this week end.