Comment 1 for bug 1229340

I've thought about annotating LVARs with information about what the nodes that use them compute. While that may be a good idea to allow further type propagation and type-directed simplification of inlined functions, it won't work for type tests.

Type tests are often of the form (or ... ...) or (and ... ...); these get compiled to conditionals, and, if we want to have decent code, we need if/if conversion to trigger. Unfortunately, as soon as that happens, the LVAR that receives the value for the initial OR/AND form disappears.

The approach in https://github.com/pkhuong/sbcl/tree/mnesic-type-tests still works: the body for each branch is annotated with special functions that track type information and detect code that is dead because of type mismatches.

However, I'm starting to think that a simpler solution will do most of the job: wrap TYPEP expanded forms with a function that is a fancy identity, (typep-info [typep-boolean] [variable] [type]). After a single round of constraint propagation, all the REF nodes have been annotated with types, and TYPEP-INFO can hopefully be converted into a constant, and otherwise simply bypassed. It's probably possible to devise code such that this simpler choice will cause worse code than the branch above, but it's also probably good enough, and definitely on the Pareto frontier for simplicity:propagation quality.