[clang] [Serialization] Load Specializations Lazily (PR #76774)

[Chuanqi Xu via cfe-commits]

ChuanqiXu9 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.
> 
> @ChuanqiXu9, you were right. We seem to not need D153003 and I have removed it from the branch.

Yeah, then let's create a new branch (the existing `[D41416_D153003](https://github.com/llvm/llvm-project/tree/users/vgvassilev/D41416_D153003)` sounds not like a good name) and a PR for that. Then I can start a stacked PR on that.

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