steffenlarsen wrote: > Does LLVM rely on each ID field having a unique address?
Based on my understanding, that is the only use-case of it. Either for RTTI or for legacy pass identification. > Does making them const mean the linker could common them up so they no longer > have unique addresses? The [C++ Standard (draft) [intro.object] ยง10](https://eel.is/c++draft/intro.object#10) says: > Unless an object is a bit-field or a subobject of zero size, the address of > that object is the address of the first byte it occupies. Two objects with > overlapping lifetimes that are not bit-fields may have the same address if > * one is nested within the other, > * at least one is a subobject of zero size and they are not of similar types > ([conv.qual]), or > * they are both potentially non-unique objects; > otherwise, they have distinct addresses and occupy disjoint bytes of storage. Since it's neither a subobject nor zero-sized, they should supply unique addresses. The example in the paragraph also shows a similar case. > Have you seen this getting misused upstream or in a downstream project? I haven't seen it happen, but to give some additional context: I'm having a look at what would be required to safely use Clang and LLVM libraries in a multi-threaded context. In such a case, any mutable global state is a risk. Having the `ID` be `const` seemed to fit the intention of it, so I decided to get ahead of the curve and propose the change now. https://github.com/llvm/llvm-project/pull/179970 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
