[llvm] [BOLT][NFC] Store FILE symbols in a vector (PR #89088)

[Amir Ayupov via llvm-commits]

aaupov wrote:

> What is the tradeoff here? Did we try on large binaries? It looks like you're trading `O(1)`'ish access for potentially `O(N)`. Can this ever be a problem?

The tradeoff is:
- storing a large unordered map Symbol (16b) -> FileName (16b) for _each_ _local_ symbol with set FileName, where we get FileName in O(1) for each local _function_ symbol (i.e. now we store strictly more than needed),
- vs a vector of just FILE symbol data (8b), where we get FileName in O(log FileSyms) * cost of FileSym->getName for each function symbol.

For reference, in one of our medium-sized test binaries we have:
- 6020 local symbols,
- 5841 local function symbols,
- 141 file symbols.

So space savings are quite significant, we gain storage locality, and an extra per-symbol cost is reasonable.

If your concern is about Symbol->getName cost, we can memorize FileName and store pairs of symbol data (8b) and StringRef (16b) instead, reducing the per-symbol cost to just O(log FileSyms).

The switch to storing FILE symbols is a prerequisite for using the symbol table information for split fragment matching.

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