llvm.org GIT mirror llvm / 1f0cde9
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240868 91177308-0d34-0410-b5e6-96231b3b80d8 Duncan P. N. Exon Smith 4 years ago
1 changed file(s) with 10 addition(s) and 0 deletion(s). Raw diff Collapse all Expand all
545545 /// This is a singly-linked list, but instead of reversing the order of
546546 /// insertion, we keep a pointer to the back of the list so we can push in
547547 /// order.
548 ///
549 /// There are two main reasons to choose a linked list over a customized
550 /// vector-like data structure.
551 ///
552 /// 1. For teardown efficiency, we want DIEs to be BumpPtrAllocated. Using a
553 /// linked list here makes this way easier to accomplish.
554 /// 2. Carrying an extra pointer per \a DIEValue isn't expensive. 45% of DIEs
555 /// have 2 or fewer values, and 90% have 5 or fewer. A vector would be
556 /// over-allocated by 50% on average anyway, the same cost as the
557 /// linked-list node.
548558 class DIEValueList {
549559 struct Node : IntrusiveBackListNode {
550560 DIEValue V;