[all-commits] [llvm/llvm-project] 7cfffe: Unittests and usability for BitstreamWriter increm...

[Mircea Trofin via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7cfffe74eeb68fbb3fb9706ac7071f8caeeb6520
      https://github.com/llvm/llvm-project/commit/7cfffe74eeb68fbb3fb9706ac7071f8caeeb6520
  Author: Mircea Trofin <mtrofin at google.com>
  Date:   2024-05-30 (Thu, 30 May 2024)

  Changed paths:
    M llvm/include/llvm/Bitcode/BitcodeWriter.h
    M llvm/include/llvm/Bitstream/BitstreamWriter.h
    M llvm/include/llvm/ProfileData/PGOCtxProfWriter.h
    M llvm/include/llvm/Support/raw_ostream.h
    M llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
    M llvm/lib/Support/raw_ostream.cpp
    M llvm/unittests/Bitstream/BitstreamWriterTest.cpp

  Log Message:
  -----------
  Unittests and usability for BitstreamWriter incremental flushing (#92983)

- added unittests for the raw_fd_stream output case.

- the `BitstreamWriter` ctor was confusing, the relationship between the buffer and the file stream wasn't clear and in fact there was a potential bug in `BitcodeWriter` in the mach-o case, because that code assumed in-buffer only serialization. The incremental flushing behavior of flushing at end of block boundaries was an implementation detail that meant serializers not using blocks (for example) would need to know to check the buffer and flush. The bug was latent - in the sense that, today, because the stream being passed was not a `raw_fd_stream`, incremental buffering never kicked in.

The new design moves the responsibility of flushing to the `BitstreamWriter`, and makes it work with any `raw_ostream` (but incrementally flush only in the `raw_fd_stream` case). If the `raw_ostream` is over a buffer - i.e. a `raw_svector_stream` - then it's equivalent to today's buffer case. For all other `raw_ostream` cases, buffering is an implementation detail. In all cases, the buffer is flushed (well, in the buffer case, that's a moot statement).

This simplifies the state and state transitions the user has to track: you have a raw_ostream -> BitstreamWrite in it -> destroy the writer => the bitstream is completely written in your raw_ostream. The "buffer" case and the "raw_fd_stream" case become optimizations rather than imposing state transition concerns to the user.



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