https://github.com/jmorse commented:
Added some shallow comments; I'm still getting my head around the major differences here and haven't looked at the tests, but see: * We're directly un-doing the effect of ODRUniqing by filtering for vulnerable retainedNodes lists on bitcode/IR load, * Types that have been ODRUnique'd get cross-scope and possibly cross-CU references to them, Which seems like a proportionate solution: ORDUniquing is saving memory in this very direct and unstructured way, and we have to work around it. Which sucks, but it's the price of the design decision. Is there any protection against a part of LLVM duplicating a type and silently getting an ODRUnique'd type back, which then leads to confusion later -- or is that what the `createIdentityMDPredicate` code is protecting against? I wonder whether this could lead to a situation where creating type metadata is vulnerable to accidents (however if it is, we should protect against it with lots of assertions, instead of trying to design around it). The potential expansion of the types being cloned due to changing createIdentityMDPredicate might affect compile-time performance; we can look at that in due course though. Thanks for sticking with this, it's been a rollercoaster, hopefully this will cover all the complications seen to date! https://github.com/llvm/llvm-project/pull/165032 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
