vgvassilev wrote: > > Let's zoom out a little. The approach in D41416 shows that it is feasible > > to store _a_ hash of the template arguments to delay eager > > deserializations. The ODR hash approach is a second order problem because > > we can swap it with something better once we need to. In order to make > > progress we have introduced [D153003](https://reviews.llvm.org/D153003) > > which allows our infrastructure to work. The way I see moving forward here > > is: > > > > * Base this PR on D41416 in the approach how we model the lazy > > deserialization of templates. That'd mean that we "just" need to replace > > `LazySpecializationInfo *LazySpecializations = nullptr;` with the on-disk > > hash table approach. That would probably require centralizing that logic > > somewhere in the ASTReader (the way this PR does) but with minimal changes > > wrt D41416. > > * Test the implementation on our infrastructure for correctness > > * Test the implementation on the Google infrastructure for scalability > > * Think on a better approach to replace odr hashing if we see more > > pathological problems. > > Yeah, no problem at all. This is what I want in the higher level too. What I > am confused is about the status of > [D153003](https://reviews.llvm.org/D153003). If it is true that we've > describe the problem completely in the review page, then > [c31d6b4](https://github.com/llvm/llvm-project/commit/c31d6b4ef135098280b0ebb93e95b258a0d372ca) > should be a proper fix for that.
I can try it on our infrastructure and if it works I will remove D153003. https://github.com/llvm/llvm-project/pull/76774 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
