Guaranteed optimizations

Motivation

Jonathan Shapiro (of BitC) makes an excellent argument that, in a systems language, it is often undesirable to depend on the whims of an ill-specified optimizer to convert abstract code into efficient machine code. The BitC specification thus includes the idea of guaranteed optimizations, to allow code to be written in a high-level style with predictably low or nonexistent runtime cost (link). Factor has also evolved a well-defined (but alas, poorly documented) "special style" that is guaranteed to be reduced to statically-typed, highly-optimized machine code by its optimizing compiler. Because Clay seeks to support systems programming with high-level abstraction, certain patterns should be guaranteed to be optimized in a certain way, instead of being left to the whims of LLVM or a C compiler. Additional optimizations should not be prevented, however.

Proposed implementation

Guarantee one or more of the following optimizations:

• Records containing one member should have the exact same ABI, including binary representation, type size, alignment, and calling convention, as the member type
  • This is incompatible with the calling convention of some C compilers, where struct { T x; } always returns by pointer even if T fits in a register. Guaranteed binary representation compatibility may have to be provided for a special wrapperType type definer
• Escape analysis of certain records or tuples, including captureValues/forwardValues tuples, lambdas, and certain user-defined types
  • A nonescaping function and nonescapingType type definer could be provided to explicitly create nonescaping tuple values and record types
• Alias analysis of ref and Pointer values
• Inlining of call sequences involving downward-only closures, nonescaping values, or guaranteed-optimized references
• etc.

It should be possible to specify that one or more of these optimizations is required, and have the compiler raise an error when they cannot be applied for some reason.

Discussion