I observed that we have the boundary comments in the codebase like: ``` //===----------------------------------------------------------------------===// // ... //===----------------------------------------------------------------------===// ``` I also observed that there are incomplete boundary comments. The revision is generated by a script that completes the boundary comments. ``` //===----------------------------------------------------------------------===// // ... ... ``` Signed-off-by: hanhanW <hanhan0912@gmail.com>
Update `BytecodeWriter` to invoke `reserveExtraSpace` on the stream before writing to it. This will give clients implementing custom output streams the opportunity to allocate an appropriately sized buffer for the write.
The config is currently not movable and because there are constructors the default move won't be generated, which prevents it from being moved. Also, it is not copyable because of the unique_ptr. This PR adds move constructor to allow moving it.
Recently there was a change to materializing unrealized conversion casts, which inserted conversion that previously did not exist during legalization (https://github.com/llvm/llvm-project/pull/97903), after these cases are inserted and then washed away after transformation completes, it caused the use-list ordering of an op to change in some cases: `my.add %arg0(use1), %arg0(use2) --> my.add %arg0(use2), %arg0(use1)`, which subtly changes the bytecode emitted since this is considered a custom use-list. When investigating why the bytecode had changed I added the following logging which helped track down the difference, in my case it showed extra bytes with "use-list section". With `-debug-only=mlir-bytecode-writer` emits logs like the following, detailing the source of written bytes: ``` emitBytes(4b) bytecode header emitVarInt(6) bytecode version emitByte(13) bytecode version emitBytes(17b) bytecode producer emitByte(0) null terminator emitVarInt(2) dialects count ... emitByte(5) dialect version emitVarInt(4) op names count emitByte(9) op names count emitVarInt(0) dialect number ... emitVarInt(2) dialect writer emitByte(5) dialect writer emitVarInt(9259963783827161088) dialect APInt ... emitVarInt(3) attr/type offset emitByte(7) attr/type offset emitByte(3) section code emitVarInt(18) section size ... ``` Note: this uses string constants and `StringLiteral`, I'm not sure if these are washed away during compilation / OK to have these around for debuggin, or if there's a better way to do this? Alternative was adding many braces and `LLVM_DEBUG` calls at each callsite, but this felt more error prone / likely to miss some callsites.
This patch is part of a project to move the Presburger library into LLVM.
The change in c1eab57 fixed the behavior of `getDiscardableAttrDictionary` for ops that are not using properties to only return discardable attributes. Bytecode writer was relying on the wrong behavior and would assume all attributes are discardable, without appropriate testing. Fix that and add a test.
When serializing to bytecode, users can select the option to elide resources from the bytecode file. This will instruct the bytecode writer to serialize only the key and resource kind, while skipping serialization of the data buffer. At parsing, the IR is built in memory with valid (but empty) resource handlers.
When emitting bytecode, clients can specify a target dialect version to emit in `BytecodeWriterConfig`. This exposes a target dialect version to the DialectBytecodeWriter, which can be queried by name and used to back-deploy attributes, types, and properties.