[all-commits] [llvm/llvm-project] d15788: Add logging for emit functions in BytecodeWriter.c...

[Kevin Gleason via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d1578848e99a9190ec9d1a5e56a5a88cb0d2649c
      https://github.com/llvm/llvm-project/commit/d1578848e99a9190ec9d1a5e56a5a88cb0d2649c
  Author: Kevin Gleason <gleasonk at google.com>
  Date:   2024-07-20 (Sat, 20 Jul 2024)

  Changed paths:
    M mlir/lib/Bytecode/Writer/BytecodeWriter.cpp

  Log Message:
  -----------
  Add logging for emit functions in BytecodeWriter.cpp (#99558)

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.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications