mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-12-09 20:46:07 +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"}
|