[llvm-dev] Why does a DISubprogram need to be distinct?

[Fangrui Song via llvm-dev]

I saw
https://reviews.llvm.org/rGe17f52d623cc146b7d9bf5a2e02965043508b4c4#949392
"Add a verifier check that rejects non-distinct DISubprogram function"
(which has currently be reverted)
today which made me wonder why a DISubprogram needs to be distinct?

David told me the following and encouraged me to ask in the upstream:

> May be historical at this point, I'm not quite sure. (I remember there being some complicated issues around distinctness of nodes when it came to inlining that could cause two inlined functions to end up smooshed together and appear as one inlined function - but I think that was about the distinctness of the debugloc itself, not of the function).
>
> Hmm, maybe it's from the days when DISubprogram ownership was inverted - DISubprograms used to be owned by the DICompileUnit and the DISubprogram would refer to the llvm::Function rather than the way it is now (llvm::Function refers to DISubprogram, DISubprogram refers to DICOmpileUnit). In that old way, deduplicating a DISubprogram when IR linking would have resulted in two DICompileUnits both having the DISubprogram in their subprogram list - which would break a bunch of other stuff.
>
> So /maybe/ not needed anymore? (given that the DISubprogram refers to the DICompileUnit which is distinct I can't see how the DISubprogram could have problems being non-distinct - but I might be missing something)

I re-generated DISubprogram-v4.ll.bc with a llc 7.0.0 in 7d0556fc137aa07347741b7750e50ecbc2b4c6e2 to fix the built bots but I am not sure I did the right thing.

* If old clang did not produce non-distinct DISubprogram, then even with the verifier I think the bitcode compatibility is still retained.
* If old clang did produce distinct DISubprogram, this seems like a bitcode compatibility break due to a verifier?