[PATCH] D153486: [llvm-profdata] GUIDToFuncNameMap can be static

[Wenlei He via Phabricator via llvm-commits]

wenlei added a comment.

In D153486#4446003 <https://reviews.llvm.org/D153486#4446003>, @davidxl wrote:

> In D153486#4445656 <https://reviews.llvm.org/D153486#4445656>, @wenlei wrote:
>
>> In D153486#4445610 <https://reviews.llvm.org/D153486#4445610>, @davidxl wrote:
>>
>>> We should consider having singleton instance and use LLVM's synchronization support to guard updating. Assuming updating the map is rare so the contention should have low runtime impact.
>>
>> Essentially this is per-module map that needs to be accessed from FunctionSamples. For local (non-distributed) ThinLTO, each thin-backend thread will build part of the map (for symbols in that module) and access that part of the map, so write is not uncommon and contention could be common. I think TLS is the best option if it's available to use.
>
> Is this map initialized once and used mostly readonly? if that is the case, serializing initialization from all threads (in the order of tens, not hundreds) is no different from one static initialization done globally.  Anyway, the effect needs to be measured to verify.

Nope. The map will be written to every time a thread picks up a new module to run thin-backend. When processing a new module, name mapping for functions in that module will need to be written to the map. So we can't really front load all writes for each thread, as this is like a per-module map.

>> OTOH, what's the total size of FunctionSamples, and how significant is saving 8 byte in it?

Sorry for delayed response. This fell through the cracks..


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153486/new/

https://reviews.llvm.org/D153486