[llvm] [DebugInfo] (Always) include the dwo name in the hash (PR #100375)

[David Blaikie via llvm-commits]

dwblaikie wrote:

Mixed feelings, but just feelings - nothing concretely wrong with the idea that I can think of.

The original change I hadn't remembered making, so thanks for doing the research/linking to the original commit - I don't think that probably triggers for ThinLTO anymore, as I guess after that change we hit other scaling problems (with just the overhead of having imported content in separate unit fragments - so many small units really added up) and also fundamental limitations regarding cross-unit referencing in Split DWARF (totally unsupported/no way to describe cross-unit references in dwo/dwp files (& not clear whether a dwo could have multiple compile units in it in any case - though since it can have some CUs and multiple TUs, multiple CUs probably falls out OK-ish... )) - and so we ended up disabling cross-cu references when using Split DWARF, and that meant the tiny imported units no longer existed and the case where there might be multiple CUs in ThinLTO no longer occurs.
(oh, this ^ would explain your comment "I'm not sure what happened, but that test was not functional right now (CHECK-NOT was matching not because the DWO_ids were different, but because the output contained only one CU)" - the original test could probably be restored, but the value would be questionable, by enabling `split-dwarf-cross-cu-references`)

But, yes, it seems quite possible to end up with a couple of units that optimize away to basically nothing... 

Though at that point, I guess there's a fair question about why the ThinLink didn't discard these units entirely - do you have an isolated reproduction of that? Might be worth looking into... - might come back to "we should home/import debug info type definitions the same way we home/import inline functions" and in the absence of that /maybe/ just having some debug info is keeping these objects alive in the link graph? But I'd be surprised if that was the case... 

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