Reapply ~"Bitcode: Collect all MDString records into a single blob"

Spiritually reapply commit r264409 (reverted in r264410), albeit with a
bit of a redesign.

Firstly, avoid splitting the big blob into multiple chunks of strings.

r264409 imposed an arbitrary limit to avoid a massive allocation on the
shared 'Record' SmallVector.  The bug with that commit only reproduced
when there were more than "chunk-size" strings.  A test for this would
have been useless long-term, since we're liable to adjust the chunk-size
in the future.

Thus, eliminate the motivation for chunk-ing by storing the string sizes
in the blob.  Here's the layout:

    vbr6: # of strings
    vbr6: offset-to-blob
    blob:
       [vbr6]: string lengths
       [char]: concatenated strings

Secondly, make the output of llvm-bcanalyzer readable.

I noticed when debugging r264409 that llvm-bcanalyzer was outputting a
massive blob all in one line.  Past a small number, the strings were
impossible to split in my head, and the lines were way too long.  This
version adds support in llvm-bcanalyzer for pretty-printing.

    <STRINGS abbrevid=4 op0=3 op1=9/> num-strings = 3 {
      'abc'
      'def'
      'ghi'
    }

From the original commit:

Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.

llvm-svn: 264551

1 files changed, 12 insertions, 0 deletions

diff --git a/llvm/test/Bitcode/metadata-strings.ll b/llvm/test/Bitcode/metadata-strings.ll
new file mode 100644
index 00000000000..9c48db5b983
--- /dev/null
+++ b/llvm/test/Bitcode/metadata-strings.ll
@@ -0,0 +1,12 @@
+; RUN: llvm-as < %s | llvm-bcanalyzer -dump | FileCheck %s
+
+!named = !{!0}
+
+; CHECK:      <METADATA_BLOCK
+; CHECK-NEXT: <STRINGS
+; CHECK-SAME: /> num-strings = 3 {
+; CHECK-NEXT:   'a'
+; CHECK-NEXT:   'b'
+; CHECK-NEXT:   'c'
+; CHECK-NEXT: }
+!0 = !{!"a", !"b", !"c"}