Move a loop invariant check out of the innermost loop. I measured a small but consistent thin link speedup from this change for a large target (0.75%).
Use the new HasLocal flag to avoid looking through all summaries to see if there is a local copy.
We are scanning through every single definition of a vtable across all translation units which is unnecessary in most cases. If this is a local, we want to make sure there isn't another local with the same GUID due to it having the same relative path. However, we were always scanning through every single summary in all cases. We can now check the new HasLocal flag added in PR164647 ahead of the loop, instead of checking on every iteration. This cut down a large thin link by around 6%, which was over half the time it spent in WPD. Note that we previously took the last conforming vtable summary, and now we use the first. This caused a test difference in one somewhat contrived test for vtables in comdats.
This patch implements the speculative devirtualization feature in the LLVM backend. It handles the case of single implementation devirtualization where there is a single possible callee of a virtual function. - Add cl::opt 'devirtualize-speculatively' to enable it. - Flag is disabled by default. - It works regardless of the visibility of the object. - Not enabled for LTO for now.
In preparation for a follow on change that will require checking every time a new summary is added to the SummaryList for a GUID, make the SummaryList private and require all accesses to go through one of two new interfaces. Most changes are to access the list via the read only getSummaryList() method, and the few that add new summaries (e.g. while building the combined summary) use the new addSummary() method.
Use `llvm::DenseMapInfo` to define `DenseMapInfo` specializations
instead of surrounding it with `namespace llvm {}`.
There's a pattern throughout LLVM of cl::opts being exported. That in itself is probably a bit unfortunate, but what's especially bad about it is that a lot of those symbols are in the global namespace. Move them into the llvm namespace. While doing this, I noticed some other variables in the global namespace and moved them as well.
Rather than passes using `!prof = !{!”unknown”}`for cases where don’t have enough information to emit profile values, this patch captures the pass (or some other information) that can help diagnostics - i.e. `!{!”unknown”, !”some-pass-name”}`.
For example, suppose we emitted a `select` with the unknown metadata, and, later, end up needing to lower that to a conditional branch. If we observe (via sample profiling, for example) that the branch is biased and would have benefitted from a valid profile, the extra information can help speed up debugging.
We can also (in a subsequent pass) generate optimization remarks about such lowered selects, with a similar aim - identify patterns lowering to `select` that may be worth some extra investment in extracting a more precise profile.
We can compute the entry count of branch funnel functions, and potentially avoid them being deemed cold (also, keeping profile information coherent is always good for performance) Issue #147390
In order to better see what's going on during ThinLTO linking, this PR adds more profile tags when using `--time-trace` on a `lld-link.exe` invocation. After PR, linking `clang.exe`: <img width="3839" height="2026" alt="Capture d’écran 2025-09-02 082021" src="https://github.com/user-attachments/assets/bf0c85ba-2f85-4bbf-a5c1-800039b56910" /> Linking a custom (Unreal Engine game) binary gives a completly different picture, probably because of using Unity files, and the sheer amount of input files (here, providing over 60 GB of .OBJs/.LIBs). <img width="1940" height="1008" alt="Capture d’écran 2025-09-02 102048" src="https://github.com/user-attachments/assets/60b28630-7995-45ce-9e8c-13f3cb5312e0" />