This extracts the string section writer and reader into dedicated
classes, which better separates the logic and will also simplify future
patches that want to interact with the string section.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Bytecode/Reader/BytecodeReader.cpp | ||
---|---|---|
295 | Shall we check on load that there is no null char in the middle of the string? | |
302 | Do you need totalStringDataSize? Isn't the same check if stringDataEndOffset == 0? | |
mlir/lib/Bytecode/Writer/BytecodeWriter.cpp | ||
232 | Still an opportunity to sort the string based on frequency, right? :) |
mlir/lib/Bytecode/Reader/BytecodeReader.cpp | ||
---|---|---|
295 | StringAttr supports strings with null characters, so I've just been allowing null holding strings in the string section (to simplify things). It doesn't affect loading at all given we don't use the null character for size computation. Do you think we should disallow that here? | |
mlir/lib/Bytecode/Writer/BytecodeWriter.cpp | ||
232 | Yeah. I've got a TODO for that in the followup Attr/Type patch as well, it should just require a bit of preprocessing (with no format changes). It wasn't clear in the beginning how annoying it would be to support, but after attr/type support I don't think it'll be too bad. |
mlir/lib/Bytecode/Reader/BytecodeReader.cpp | ||
---|---|---|
295 | Not necessarily, but I remember some doc on the bytecode that was explicit about null-terminated string which excluded null char? |
Shall we check on load that there is no null char in the middle of the string?