[PATCH] D16277: Bitcode: use blob for string storage in the IR: trade a bit of space for faster reading

Mehdi AMINI via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 18 10:59:24 PST 2016


joker.eph added inline comments.

================
Comment at: include/llvm/Support/StreamingMemoryObject.h:34
@@ -30,9 +33,3 @@
                      uint64_t Address) const override;
-  const uint8_t *getPointer(uint64_t address, uint64_t size) const override {
-    // FIXME: This could be fixed by ensuring the bytes are fetched and
-    // making a copy, requiring that the bitcode size be known, or
-    // otherwise ensuring that the memory doesn't go away/get reallocated,
-    // but it's not currently necessary. Users that need the pointer (any
-    // that need Blobs) don't stream.
-    report_fatal_error("getPointer in streaming memory objects not allowed");
-    return nullptr;
+  const uint8_t *getPointer(uint64_t Address, uint64_t Size) const override {
+    Buffer.resize(Size);
----------------
filcab wrote:
> What happens if there's two BLOBs in the stream? Wouldn't you overwrite one with the other?
Yes the validity of the pointer returned last only till the next read from the stream. 
The model is that there will be a copy made by the client anyway. But with blob won't "unpack" 6 bits elements to an array of unsigned, and then decode the 6 bits encoding to char, and then do the copy.

Note also that I haven't find another place than llvm-dis that uses this code-path.


http://reviews.llvm.org/D16277





More information about the llvm-commits mailing list