[LLVMdev] RFC: Reduce the memory footprint of DIEs (and DIEValues)
Duncan P. N. Exon Smith
dexonsmith at apple.com
Wed Jun 17 11:26:26 PDT 2015
> On 2015 Jun 16, at 21:40, Yaron Keren <yaron.keren at gmail.com> wrote:
> Hi Duncan,
> Singly linked lists are used throught LLVM: ArrayRecycler, Registry, LiveInterval, SCEVUnknown, CGBlockInfo, MacroArgCache, ...DIEValueList.
> What do you think about implementing a singly-linked ADT?
I've taken a look at the other singly-linked lists you mentioned. Most
of these are some version of a free/recycling list (ArrayRecycler,
Registry, MacroArgCache, etc.), which need super simple push/pop API and
no memory management.
LiveInterval and CGBlock also need iteration and a way to conditionally
remove elements (something like `remove_if()`), and in a few cases it
would be convenient to have API to destruct and/or destroy nodes.
I think these would all be straightforward to formalize into an ADT. We
could even use it to implement a value-based `llvm::forward_list<>` that
avoided the sorting bug in libstdc++ (which gets "stable" exactly
backwards) that David hit when refactoring tablegen.
Unfortunately, I think it'd be hard to reuse for DIE::Children and
DIEValueList. The latter wants to preserve insertion order and needs
`push_back()` API (the former can technically get away with a timely
call to `reverse()`, but it's awkward). Supporting `push_back()`
efficiently requires pointing at the last element somehow, either via an
extra pointer or circular logic (what my latest patch does for
We could configure this stuff via templates -- I'd be open to the idea
-- but I think the intersection between the implementations would be
practically nil. Even the iterator implementations need to be
completely different. If these are the only `push_back()`-enabled
slists in tree, is it premature to abstract it? Would we even want the
same name as "normal" slists?
(Regardless, I think it would be a great idea for someone to ADT-ify the
other linked lists!)
> 2015-06-05 3:24 GMT+03:00 Duncan P. N. Exon Smith <dexonsmith at apple.com>:
> > On 2015 May 28, at 14:14, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> >> On 2015-May-26, at 15:30, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> >> David, let me know if you have any comments on the `DIE::Children`
> >> stuff (patch 0008 in particular, although I think Eric wanted your
> >> opinion on 0007 as well).
> >>> On 2015-May-26, at 14:41, Eric Christopher <echristo at gmail.com> wrote:
> >>> 0007 - LGTM, might want to have Dave take a look at it as well.
> >>> 0008 - reverseChildren and finalizeChildren is pretty gross. Also, I'm going to punt on the rest of this to Dave.
> > I've committed all but these two. I've attached rebased versions
> > that incorporate (most of) Fred's feedback.
> > David, I found a way to avoid the reverseChildren/finalizeChildren
> > thing without paying for an extra pointer, but it means that
> > `DIE` would no longer use `std::unique_ptr<>` internally. (High
> > level: change the sibling list to a circular linked list, point at
> > the last child instead of the first, and store a "this-is-last"
> > marker on the last child to support iteration.)
> > stop-reversing-children.patch implements this on top of 0008;
> > stop-reversing-children-with-0008.patch has that patch and 0008
> > merged together. I think this might be the better way to do it,
> > but I'm open to other ideas.
> > If you're okay with this approach, maybe I'll rewrite 0007 to
> > save an extra pointer there as well?
> Ping. Patches reattached.
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits