Frontend Holes

[stephenverderame]

This is quite a large PR, and I've been working sporadically on this for quite some time, so I don't think I even know everything that changed off the top of my head right now. I do want to write a blog post or two going through some things in more detail.

Generally, I assumed that the explicator only explicates within a funclet, so the frontend still errors if it can't determine types for anything that might cross a funclet boundary. The previous type deduction algorithm is still in use, just with some new features.

The frontend also does a little bit of (polynomial time) synthesis itself now to determine when to make a mutable variable usable if the user never explicitly writes to it. Unless the program is ill-formed, the solution will always be valid, but not necessarily globally optimal, However, the solution has a property that can be thought of as local optimality.

Otherwise, the frontend type deduction should only make unambiguous decisions that can't be wrong, requiring type annotations if something can't be deduced. In all cases, the user should be able to specify what they want with type annotations.

• The ? Hole. It's not clear to me whether this is something we'd want in the long run or just want to fold it into the ???. Basically, this corresponds to the assembly ? and roughly the semantics of this can be thought of as ? is an expression that can take the value of any variable that reaches it. Where "reaches" here is defined to consider that references can't cross funclet boundaries and how variables are consumed. So in Sketch, ? is basically {| v_1 | v_2 | ... | v_n |} where v_1, ..., v_n are variables that reach ?. Note ? cannot dereference references. As a consequence of how renaming is used for shadowing variables, a hole can use a shadowed variable right now.
• The ??? hole. This can be used as an expression or statement and allows for arbitrary codegen by the explicator. Like ?, it effectively uses every variable that reaches it.
• Undefined variables are given definitions at the hole that dominates all uses with the shortest path to the CFG end block. It is assumed that variables a hole defines are also initialized (made usable) at that point. ??? as an expression will generate assembly corresponding to an allocation of a temporary, a big hole, then a use of the temporary. I'm not sure if this is better or worse for the explicator than just a big hole and a small hole.
• A ReachingDefs pass that calculates reaching defs and ensures that all definitions reach their uses.
• Unitiaized mutables that need to be initialized (made usable) are initialized at the ??? holes which correspond to the "optimized latest possible point". That is we start initializing mutables at the latest possible point and then hoist the initializations as high as possible such that the new initialization set is strictly better than the previous one.
• An UninitCheck pass that is similar to ReachingDefs but ensures that variables are initialized at every use they are needed to be usable.
• A fix to type unification that allows multiple variables to be stored to in branches of if. Previously, it would break if anything other than the spec's result of the if was stored to in a branch of the if. In other words, it was assumed that frontend PHI nodes always correspond to an if in the spec, which isn't always true. For example, we could write the same value to a variable in both branches of an if.
• Slightly better error messages and a demangling of variable names when displaying them in errors. Something to maybe do in the future is provide better displaying of errors that occur on variables that the frontend generated. Also, it could be desired to support displaying more than one error at a time.
• Special _ variable name. This is a regular variable, except that the name _ can only be used in a variable definition. Due to renaming, the assembly will see this as _%n for some integer n.
• Some notes on frontend name mangling (in case you need to debug something). In the following n represents some integer.%n is a suffix for AST-level SSA renaming to support things like scoping and shadowing. .n is a suffix for IR level SSA renaming, which considers writing a new "definition". _v_ref is for the underlying reference of the mutable variable named v (as mutable variables in the frontend have value semantics). ! is used to prepend meta-variable names in type unification to gen a new intermediate variable. $ is used to prepend all spec variable names (class names) in type unification. _hn is for the implicit definition(s) of a ??? hole when it's used as an expression. _fn is for AST-level temporaries created by flattening. _tn is for assembly-level temporaries created by lowering. _t_v1_v2_..._vn is a tuple of variables v1 to vn. So for example _c%0_ref.0 is the original definition of the backing reference of some user mutable variable c.
• A simple FileCheck like script for testing test output
• All GPU variables now always have flags storage, map_read, and copy_dst. (The type name suffix ::gds where g stands for GPU, s is for source (copy_dst), and d is for destination (map_read). This isn't ideal, but deduction of these might not be possible in cases with holes where it becomes unknown all the ways a variable is used.
• Various changes and improvements internal to the frontend