[llvm] [DWARFLinkerParallel] Add support for -odr mode. (PR #68721)

[via llvm-commits]

avl-llvm wrote:

> DWARFLinker would still need to be deterministic, even on old/bad/different input - though maybe Apple & other folks would be open to it having an error on "bad" input rather than having to figure out a way to have a deterministic successful output.
> 
that could be done with the cost of slower execution.
Currently, first met definition is copied into the resulting DWARF and all other declarations/definitions are skipped.
Instead all met declarations/definitions could be united. i.e. final type description would have attributes from all type copies. In that case final DWARF would be the same despite of the order of compile units handling.

> That said - I'm always here for a conversation about type consistency in DWARF... so let's take a look:
> 
> `DominatorTreeBase<llvm::BasicBlock, false>` example - `Insert` is a `static constexpr SomeEnum` member with an in-class initializer. Hmm, that might be tricky to do - because technically this isn't a definition (there may be no storage behind it) so I'm not sure we could move the const value out into a separate definition DIE. I guess a definition DIE without a DW_AT_location would be the nearest DWARF-ish way to express it. We /might/ be able to always instantiate the definition value, so put it on the declaration in all cases, but would need some language expertise to check if that's do-able.

Speaking of original example, Do I correctly understand that "DW_AT_const_value   (0)" should be in both type definition copies(0x001c4090 and 0x010f623d) in currently generated DWARF?

> 
> `SmallVectorImpl<llvm::Instruction *>` example - I'm not sure why we'd sometimes put the parameter name in and sometimes not. That seems unlikely to be intentional/particularly deeply thought out, but of uncertain difficulty to fix.

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