[lld] [llvm] Reapply "Use an abbrev to reduce size of VALUE_GUID records in ThinLTO summaries" (#90610) (PR #90692)

[Jan Voung via llvm-commits]

jvoung wrote:

Thanks @kamaub for looking into this more, and for instructions on how to reproduce (I can repro now).

Another thought is if it makes sense to change the `config.lto_supported` [detection](https://github.com/llvm/llvm-project/blob/d92c67784f21063d6334a009dbf4f9e0f8217b41/compiler-rt/test/lit.common.cfg.py#L753) in the Linux+LLD case to check that LLD is built and thus understands the latest changes like the version, and not a possibly old copy of LLD. For example, in the Linux+Gold case it checks `os.path.exists(os.path.join(config.llvm_shlib_dir, "LLVMgold.so"))`, or in the Windows case it checks `os.path.exists(os.path.join(config.llvm_tools_dir, "lld-link.exe"))`. Can we then check `os.path.exists(os.path.join(config.llvm_tools_dir, "lld"))` ?

@MaskRay you mentioned something like this is in https://github.com/llvm/llvm-project/commit/746b5fad5b53ddbc78d36a6b97dcaff7e52540b2  

Would making the `lto_supported` stricter make sense, or do you have a recommendation here?

Then the test should probably check if feature `lto` is available (since it adds flags `-flto`). There is some interesting fallback [here](https://github.com/llvm/llvm-project/blob/ec36145f58d2cf93d86bc4e3be617ad7d7d8ace7/compiler-rt/test/profile/lit.cfg.py#L67) where it checks `lto_supported` and may choose not to add `-flto`, but currently the test unconditionally adds `-flto`. 


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