mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-12-04 01:11:44 +00:00
1fbdccf334
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
13 lines
265 B
LLVM
13 lines
265 B
LLVM
; 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"}
|