This is a list of things that need to be worked on. It will hopefully be complete soon. Correctness ----------- - Debugging info (check & fix as much as we can) Optimizations (better compiled code) ------------------------------------ - Reduce register pressure in scheduler - More strength reduction: multiply -> shift/add combos (Worth doing?) - Add a value range propagation pass (for bounds elim & bitwidth reduction) - Make dead store pass inter-block - If there are a lot of MOVQ $0, ..., then load 0 into a register and use the register as the source instead. - Allow arrays of length 1 (or longer, with all constant indexes?) to be SSAable. - If strings are being passed around without being interpreted (ptr and len fields being accessed) pass them in xmm registers? Same for interfaces? - Non-constant rotate detection. - Do 0 <= x && x < n with one unsigned compare - nil-check removal in indexed load/store case: lea (%rdx,%rax,1),%rcx test %al,(%rcx) // nil check mov (%rdx,%rax,1),%cl // load to same address - any pointer generated by unsafe arithmetic must be non-nil? (Of course that may not be true in general, but it is for all uses in the runtime, and we can play games with unsafe.) Optimizations (better compiler) ------------------------------- - OpStore uses 3 args. Increase the size of Value.argstorage to 3? - Use a constant cache for OpConstNil, OpConstInterface, OpConstSlice, maybe OpConstString - Handle signed division overflow and sign extension earlier Regalloc -------- - Make less arch-dependent - Handle 2-address instructions - Make liveness analysis non-quadratic Future/other ------------ - Start another architecture (arm?) - 64-bit ops on 32-bit machines - Investigate type equality. During SSA generation, should we use n.Type or (say) TypeBool? - Should we get rid of named types in favor of underlying types during SSA generation? - Should we introduce a new type equality routine that is less strict than the frontend's? - Infrastructure for enabling/disabling/configuring passes