We were using a StringMap object to store all profiles to be emitted. The object is basically an unordered hash table, therefore updating it in the process of trasvering it may cause issue since the underlying bucket array could change.
I'm also moving the csspgo-preinliner switch around so that no context tri will be constructed (by the constructor of CSPreInliner) when the switch is off.
Good catch - not sure how I come to incorrectly rely on the order of StringMap..
However the intention was to avoid extra copies of FunctionSamples as much as possible - these can large objects for copying.
I think what we could do is to collect a std::map<StringRef, StringRef> (old context to new context) for how we should update the StringMap, then iterate over the (top-down) ordered std::map to move profile to be keyed by correct context. This way we can avoid one extra copy for each FunctionSamples that needs to be moved.