[llvm] Reduce llvm-gsymutil memory usage (PR #91023)

Alexander Yermolovich via llvm-commits llvm-commits at lists.llvm.org
Thu May 16 10:33:37 PDT 2024


ayermolo wrote:

> > > > Per my understanding, these two mutex are required to protect any read/write to DieArray field? If so, there seem to be many more accesses of this field not protected?
> > > 
> > > 
> > > They're there for protecting the allocation+population, or destruction of the DieArrays, not generally reading/writing those fields. There needs to be two (for just the first CUDie, and then the whole array) as populating the first can trigger a request to populate the rest.
> > 
> > 
> > What is the code path for that?
> 
> Sorry: I wrote that backwards (fixed the original comment). Populating the full array can trigger a request to populate the CuDie through `determineStringOffsetsTableContribution`, which is why you need the two different locks. The first is always created before the list, but you need to lock it separately so that the read-lock will be free to return just the CUDie.

Glanced at the code. I think I am missing something. How can code through determineStringOffsetsTableContribution trigger the path? It just accesses StrOffset Section.

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


More information about the llvm-commits mailing list