Resources are encoded in two separate sections similarly to
attributes/types, one for the actual data and one for the data
offsets. Unlike other sections, the resource sections are optional
given that in many cases they won't be present. For testing,
bytecode serialization is added for DenseResourceElementsAttr.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
(only partial scan)
mlir/docs/BytecodeFormat.md | ||
---|---|---|
105 | allows ? | |
107 | So the padding is already in file to allow for memory mapping? Or why padding in file? (Unless mistaken one could just had alignment considered when allocating) | |
272 | And this is index into string pool? | |
mlir/lib/Bytecode/Reader/BytecodeReader.cpp | ||
92 | I don't recall max alignment being specified above. | |
93 | Where does this come into effect? E.g., if i had 12, where would it fail further? (I mean I can't think of when it would be useful) | |
114 | An error without a message but just location? |
mlir/lib/Bytecode/Reader/BytecodeReader.cpp | ||
---|---|---|
114 | I missed that this was InflightDiagnostic so intended for streaming. | |
509 | The newlines between functions or not here is a bit confusing (seems 2 together, newline, 2 together ...) and I can't make much sense of why. Lets have newline between all of the parse methods for consistency. | |
509 | Where is this function used? | |
627 | Is the expectations around these documented somewhere? E.g., they need to initialized already or some such. So currently we'd emit a warning and skip over? | |
631 | Is a continue needed here? | |
mlir/lib/Bytecode/Writer/BytecodeWriter.cpp | ||
101 | Where is this verified before here? E.g., if a file has an invalid alignment where would that be flagged before we get here. | |
237 | Where is this used? | |
mlir/lib/Bytecode/Writer/IRNumbering.cpp | ||
365 | buildBlob before buildBool ? | |
mlir/lib/Bytecode/Writer/IRNumbering.h | ||
95 | Is this naming convention used for resources? (extern vs not, declaration vs definition) | |
122 | SetVector here reminds me: do we have a test for consistent serialization? E.g., given same input you have same output (e.g., would we have detected if we used wrong set data structure here) | |
mlir/lib/IR/BuiltinDialectBytecode.cpp | ||
406 | Is this intended to be in the same order as AttributeCode ? | |
453 | Would readResrouceHandle emit an error? |
mlir/docs/BytecodeFormat.md | ||
---|---|---|
107 | Yeah, the padding is there to ensure that the data is already at the correct alignment in-file (e.g. to support mmaping). | |
272 | Yep | |
mlir/lib/Bytecode/Reader/BytecodeReader.cpp | ||
92 | Do you have any suggestions on how we should approach that? Realistically an upper limit on any system would be something like PAGE size. We want to allow "larger" alignments (at least larger than std::max_align_t), e.g. given that some places want larger alignments when processing the data. | |
93 | We could technically allow it (by aligning to the next power of 2 and just padding to the weird alignment), but I don't have a use case and it's easier to just disallow for now. | |
509 | It's a virtual function, it's called by users parsing resources. | |
627 |
I need to finalize the docs for them and send that out.
Yep. | |
631 | No, we still need to skip over the entries, we just don't process them. There is a "continue" in parseGroup for the case of a null handler. | |
mlir/lib/Bytecode/Writer/BytecodeWriter.cpp | ||
237 | It's used, e.g., when emitting a section into another one (see emitSection above). | |
mlir/lib/Bytecode/Writer/IRNumbering.h | ||
95 | It is for dialect resources. We declare before defining, i.e. this is how the handles work (you can have a handle to a resource that isn't fully defined). | |
122 | Added. It's also quite difficult to break this given that the API for resources requires passing in a SetVector, so we'd have to purposefully use something else and then construct a SetVector (which would give a werid code smell). | |
mlir/lib/IR/BuiltinDialectBytecode.cpp | ||
406 | No, given that we might have different AttributeCodes for the same attribute. It's cleaner to just use alphabetical order here, given that we shouldn't try to derive a connection between the two. I do group Locations separately, but that's mostly conventional with how we group builtin attributes in switches elsewhere in the codebase. | |
453 | Yep. |
Nice, like the structure containing the resource info.
mlir/lib/Bytecode/Reader/BytecodeReader.cpp | ||
---|---|---|
92 | I don't really ... Perhaps a TODO for now and we can come back to it. PAGE seems appealing, but for now lets trust the user here. | |
mlir/lib/IR/BuiltinDialectBytecode.cpp | ||
406 | Ah so alphabetical but with with locations at end, could you add a // Locations or some such, I missed that. |
mlir/lib/Bytecode/Reader/BytecodeReader.cpp | ||
---|---|---|
92 | Added a TODO, I'll add an error in a followup. |
allows ?