aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/MC/MCAssembler.cpp
diff options
context:
space:
mode:
authorDuncan P. N. Exon Smith <dexonsmith@apple.com>2015-06-27 01:19:17 +0000
committerDuncan P. N. Exon Smith <dexonsmith@apple.com>2015-06-27 01:19:17 +0000
commit203cbe7f6f53c5e95ebf4f870bb9dae53a0a5c72 (patch)
tree56c155c7dccd2319a744f7406ecd69e70f724c20 /llvm/lib/MC/MCAssembler.cpp
parent1f8a99a9ae8c22ac1c90ee623d132ca0ee4bc0f5 (diff)
downloadllvm-203cbe7f6f53c5e95ebf4f870bb9dae53a0a5c72.zip
llvm-203cbe7f6f53c5e95ebf4f870bb9dae53a0a5c72.tar.gz
llvm-203cbe7f6f53c5e95ebf4f870bb9dae53a0a5c72.tar.bz2
AsmPrinter: Document why DIEValueList uses a linked-list, NFC
There are two main reasons why a linked-list makes sense for `DIEValueList`. 1. We want `DIE` to be on a `BumpPtrAllocator` to improve teardown efficiency. Making `DIEValueList` array-based would make that much more complicated. 2. The singly-linked list is fairly memory efficient. The histogram [1] shows that most DIEs have relatively few values, so we often pay less than the 2/3-pointer static overhead of a vector. Furthermore, we don't know ahead of time exactly how many values a `DIE` needs, so a vector-like scheme will on average over-allocate by ~50%. As it happens, that's the same memory overhead as the linked list node. [1]: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/085910.html The comment I added to the code is a little more succinct, but I think it's enough to give the idea. llvm-svn: 240868
Diffstat (limited to 'llvm/lib/MC/MCAssembler.cpp')
0 files changed, 0 insertions, 0 deletions