[PATCH] D137933: [llvm-debuginfo-analyzer] 08a - Memory Management
David Blaikie via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 19 10:48:18 PST 2023
dblaikie added a comment.
> This involves quite a lot of changes specially in the CodeView Reader which uses visitor modules (logical, types and symbols) to traverse the debug information.
Whenever I see this mentioned, I get pretty skittish - the solution chosen shouldn't be dependent on how much code churn is involved (because it's the LLVM coding standards we're concerned with before accepting this code into the LLVM project).
But if it's the right solution regardless of cost, I'm more inclined/comfortable with it.
Is this API purely a "build/growth" without ever modifying? (like Clang's AST which uses bump/arena allocation - because you can't mutate the AST after it's built - you can't remove nodes, change nodes, etc)
In which case was the old design excessively chatty about allocation management, given that monolithic nature of the data structure?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D137933/new/
https://reviews.llvm.org/D137933
More information about the llvm-commits
mailing list