[llvm] [llvm-debuginfo-analyzer] Remove `LVScope::Children` container (PR #144750)

Javier Lopez-Gomez via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 19 08:09:19 PDT 2025


jalopezg-git wrote:

> > This PR should yield further memory footprint improvements after #144399 is merged.
> > As suggested in #69160, removing `LVScope::Children`. Note, however, that children iteration order is now _(1)_ Types, _(2)_ Symbols, and finally _(3)_ Scopes. This may be (or not) considered important - I think it's not. ` llvm-debuginfo-analyzer` tests should be fixed though due to iteration order and `CHECK-NEXT:` FileCheck directives used in those tests.
> 
> From [#69160 (comment)](https://github.com/llvm/llvm-project/issues/69160#issuecomment-2987673689)
> 
> The idea behind the `Children` container is to generate a logical view where its logical elements order is very close to their programming elements from the input file. That is the default printing mode. By using the chaining iterator, we hope to have a considerable memory reduction, which is very important. May be we can use the `LVObject::ID` to recreate the original printing order via the `LVSortFunction llvm::logicalview::getSortFunction()`.

@CarlosAlbertoEnciso If order is important, then...
- (1) `getChildren()` may return `llvm::SmallVector` instead, which is composed on demand by adding element from the other vectors and sorting as appropriate (e.g. by `LVObject::ID`).  
The problem w/ this one is that `getChildren()` has an associated overhead, but we could likely offer `getUnorderedChildren()` which iterates as-is (current state of this PR).
- OR... (2) the `Children` member may be kept, but its encoding may change s.t. it uses less memory, e.g. instead of using pointers, we may use `int32_t` where the first `N` most-significant bits are used to store which vector does the element belong to, and the remaining bits are an index.
This should cut memory consumption at least by half, depending on the type used.

I'm thinking about this, but likely we could go for approach _(1)_, and if overhead is a concern, one should use `getUnorderedChildren()`.  What do you think?

https://github.com/llvm/llvm-project/pull/144750


More information about the llvm-commits mailing list