This is an archive of the discontinued LLVM Phabricator instance.

Split TypeTableBuilder into two classes
AcceptedPublic

Authored by zturner on Nov 29 2017, 5:03 PM.

Details

Reviewers
rnk
Summary

I struggled with this for quite a while, but the motivation for this is the desire to add a different hashing strategy that can be selected at runtime while maintaining backwards compatibility with the existing hashing strategy until the new method is robust and we can be certain it does not cause any regressions (correctness or performance).

The problem is that we pass TypeTableBuilder references around in many scenarios, but a lot of the places we use them are ignorant of whether or not the type table is in de-duplication mode. On the surface this seems neat, but we need to be able to change the interface in ways that only make sense when the builder is hashing. If we try to cram it all into a single interface again, I think we run into the problem we had before with TypeSerializer where it was just doing too much, and as a result there were a lot of strange states you get the class into.

It turns out that all of the places that were agnostic about the de-duplication mode was just by chance. In all of those cases, there was actually only one single mode that made sense, so splitting the class into a de-duplicating type table and an appending type table did not cause any serious problems.

After this patch, the two interfaces will be able to diverge so that we can provide a better interface for the hashing version of TypeTableBuilder.

Diff Detail

Event Timeline

zturner created this revision.Nov 29 2017, 5:03 PM
rnk accepted this revision.Nov 29 2017, 5:22 PM

lgtm

This revision is now accepted and ready to land.Nov 29 2017, 5:22 PM