cache the results of type projection and normalization

[nikomatsakis]

Both in trans and in typeck. Must be somewhat careful around type parameters and so forth. Probably we want to introduce a cache onto the fulfillment context to use for normalization as well.

[freebroccolo]

cc me

[arielb1]

cc me (this seems to take 10% of no-opt time).

[DemiMarie]

Which functions in the compiler need to be memoized?

[jonas-schievink]

@drbo FulfillmentContext::normalize_projection_type

[Marwes]

I was thinking about implementing this but I have run into some trouble. From what I can gather it is possible for type inference to try multiple different alternatives before it finds the correct typing. This means that types returned after normalizing and selecting associated types may actually be wrong and thus cannot be cached.

Is there some way/place where it is known that the result of normalizing is actually the correct way so that caching can be done correctly? The other way I thought of doing it is to rely on the snapshoting in the InferCtxt so that bad types can be rolled back but my implementation still seems to cache bad types in that implementation.

[nikomatsakis]

It's worth nothing that over the last week or so I've been drawing up plans
for overhauling this part of the compiler. Under the new design I am
currently considering, there isn't even a notion of normalization per se
(rather the compiler tracks "congruent" types using a congruence closure
algorithm). I intend to try and write this up over the next few days.

On Mon, Mar 7, 2016 at 12:10 PM, Markus Westerlind <notifications@github.com

wrote:

I was thinking about implementing this but I have run into some trouble.
From what I can gather it is possible for type inference to try multiple
different alternatives before it finds the correct typing. This means that
types returned after normalizing and selecting associated types may
actually be wrong and thus cannot be cached.

Is there some way/place where it is known that the result of normalizing
is actually the correct way so that caching can be done correctly? The
other way I thought of doing it is to rely on the snapshoting in the
InferCtxt so that bad types can be rolled back but my implementation still
seems to cache bad types in that implementation.

—
Reply to this email directly or view it on GitHub
#20304 (comment).

[Marwes]

I will hold off working on this then. Looking forward to seeing this issue resolved.

[nikomatsakis]

So, actually, I've been rethinking my "rethinking". That is, I now think the work on congruence closure is of secondary importance and can be deferred. I've implemented a simple cache for projection -- I have plans for a more elaborate one -- but it seems to be effective e.g. for the example in #31849.

[Mark-Simulacrum]

@nikomatsakis Is this still a problem today?

[ishitatsuyuki]

This is still a thing today, although I've improved the situation in #48296 by reducing the complexity of recursion itself.