I remember implementing this decades ago. Brings me back to see it again :) Your implementation looks nice. You are right that often lots of lattice tricks an

I remember implementing this decades ago. Brings me back to see it again :) Your implementation looks nice. You are right that often lots of lattice tricks and such are played in real implementations. If you are worried about speed and memory usage while dealing with context sensitivity, and want to make the lattice taller or wider, incorporate BDD's or a similar mechanism. Somewhat pointless for single-functions, but as context-sensitivity grows, you either need BDD's or summaries (or some form of auto-sharing) if you want to represent nice large lattices. Lattice value bdd's are a thing too, so you don't have to spend a bunch of time figuring out how to represent the lattice as a BDD (alternatively, you can do something like Souffle and friends that will take care of it under the covers) :) This is the historically normal mechanism for effective representation of this sort of problem, because it deals with sharing of equivalent values/etc for you. Also, if you want later passes to take advantage of the final lattice information, there are ways to represent it in the IR effectively, the same way you would with value ranges. In value ranges, you would do: if (a0 > 5) { a1 = range_info(a0, >5) } else { a2 = range_info(a0, <=5) } You can do the same thing with the final type info to pass it along to later things. The limit of this kind of splitting is basically SSI and friends. If you are interested in the general theory of splitting and using it to represent info or solve other types of problems faster, see: https://arxiv.org/pdf/1403.5952 https://arxiv.org/pdf/1403.5952 and friends.