JIT: consolidate type tracking mechanisms

[AndyAyersMS]

We now have several complementary systems in the importer for tracking types: the evaluation stack, local variable class tracking, and the tree node extraction tracking (gtGetClassHandle).

These are interdependent and vary in their capabilities:

• The evaluation stack can't track exactness or non-nullness, two properties that are useful and can be ususally be deduced when the stack entry is created.
• Local variable tracking can't track non-nullness, and this may be tricky to do since it is flow dependent. But some cases are potentially knowable, eg "single-def" temps introduced by the compiler for newobj or for callee arguments. Also there is some overlap with the explicitly tracked classes and the verifier type info used at some places in the compiler.
• Tree node extraction can only handle subsets of cases, and because of the enormous variability of expansion (eg the many ways a ldsfld can expand to trees) can't be made fully general unless information is more directly represented on the tree nodes.

The stack is only available during importation, while the local var and tree node information is potentially available later on, during inlining and optimization passes. The tree node evaluation as it is done now should remain correct. However if type information is cached on tree nodes then we need to be careful to consider what should happen when tree nodes are bashed or otherwise destructively updated. We may also experience loss of types as new nodes are created. The local variable information is somewhat fragile though it is unlikely that optimizations would introduce new definitions or change the types of existing definitions. However there is nothing to prevent this or to check that it hasn't happened.

It would be good to unify the capabilities of these systems and work on better defining the maintenance/invalidation process.

Doing this would allow the compiler's type based optimizations to be done safely at various points in the compilation pipeline, and would make them less dependent on IL patterns or runtime expansions.
category:implementation
theme:importer
skill-level:expert
cost:large