Add static allocation support in Rssa through codegen

[jasoncarr0]

The later IRs now support static data of various sorts. Some features are merged into statics: isMutable in Rssa has been weakened to pinned which is only needed to maintain the changes from BounceVars without excessive liveness analysis. The vectors field of Machine.Program.T has been changed to include general statics. In Rssa, a new expression defines a unique static for each usage in the program. In the backend, statics are moved into the program (no uniqueifying is performed, as it seems to be an artifact of propagation of constants), and references are done through an operand. The operand Static is a constant value which has type CPointer or ObjPtr, and its data can be accessed with Offset/Contents as normal. Thus, it has no address, and it cannot be written to (which indicated some conflations of meaning for isLocation).

Under the default behavior, globals are not statically allocated if they have one or more mutable fields which can hold an object pointer (after packing) or if their data is not statically allocated. In practice, there are no such globals for just about all programs.

This version has support in all codegens. As expected, code size and compile time are improved across the board, particularly for larger programs. Runtime improves sometimes, but should only affect programs which had hot code accessing globals, as it removes one level of indirection. We should also expect marginally faster garbage collections, as globals are now mostly skipped.

A couple pieces are still outstanding for discussion and review:

• Command line options. There's a lot of dimensions to this, and in general they should all be enabled unless a bug or performance regression arises in user code, or a GC choice makes them impossible. Right now disabling it for particular sorts of data still leaves them statically initialized (and heap allocated), but ...
• Objects which are not statically allocated are currently created in code. It seems not to be worth it to make a statically initialized heap allocated object, as the code to initialize them is quite small. The statically allocated objects should have better compile time though.
• There's still a good bit of complexity that I'd like to reduce as much as possible of. Some options are partially coupled: generally the heap allocated statics are precisely the statics with destination globals. As an awkwardness with this, which de-facto cannot occur (due to propagation), is a non-heap static with global, which would be copied to the heap under the current code (but doing something else would be an additional edge case). Empty (array) data has to have different initialization rules from others to avoid executable bloat (so it goes in bss, instead of text). I have at least managed to center all decision-making to ssa2-to-rssa and all initialization to c codegen's outputDecls.
• Rssa still has WordXVector support for constants. Only one particular pass in Rssa created them, so it may be easiest to just disable it, which would simplify the backend and reduce redundancy. The complexity here is that disabling this requires duplicating or factoring the logic for deciding where to place statics (WordXVectors are only placed on the heap at the moment).
• Statics are somewhat inconsistent with globals: they are stored with the program, and information about them is local, whereas globals are created and stored globally, but I couldn't convince myself to create a module just for a single integer counter.

This resolves #300

This affects the previous globalization changes in #288, so they should be re-examined as well. In particular effects due to extra indirections should disappear, so remaining effects will only be due to low-level perturbations and interactions with other passes (local-ref for instance).

[MatthewFluet]

I was struggling to find/write a source program that, with -static-alloc-internal-ptrs static -static-alloc-objects true -static-init-objects all, would trigger this code path that leads to a statically initialized but dynamically allocated object. Eventually, I realized that there should be no such objects. With -static-alloc-internal-ptrs static -static-alloc-objects true, the only objects that will be statics with a Heap location are objects with a mutable Objptr field. Moreover, only global objects are eligible to be statics. But, assuming a safe-for-space globalization pass, there should be no global objects with mutable Objptr fields (because global objects are roots for the whole program execution). I seem to remember @jasoncarr0 making some comment that was supposed to suggest this (something along the lines of "by fiat, should never happen"), but I can't find it right now.

Using -globalize-small-types 9, which allows the globalization of arbitrary array and ref objects (irrespective of the "size" of their contents), then we can trigger global objects with mutable Objptr fields that become statically initialized, dynamically allocated.

With this observation about safe-for-space, I'm not understanding why there should ever be a non-empty globalObjptr[] array. In a self-compile, there are 26.

[jasoncarr0]

It can happen, if globalize-small-type 4 is on, then an example would be a mutable field of a tuple of total size more than 64 bytes. It is safe to globalize, but will turn into an Objptr in Rssa. With the current code, intInfs aren't included only because they're infrequent, so that would explain some globalObjptrs on a self-compile.

[jasoncarr0]

Unless I've made a mistake in understanding packed-representation here

[MatthewFluet]

You are right, that a (int * int) ref could be space-safely globalized and could result in an object with a mutable Objptr field. However, it is also likely that such a tuple would be RefFlattened; I suspect that is why we don't see many of them. As you say with -globalize-small-types 4, then we might have a (int * int, int * int) either ref be globalized.

Also, it turns out that we "grandfathered" IntInf.int as a "small type"; so a IntInf.int ref can be globalized, but is represented as an object with a mutable Objptr field.

[MatthewFluet]

Finally, we might have an IntInf.int ref ref; the inner ref might be statically initialized (but dynamically allocated), so the outer ref could not be statically initialized.

[MatthewFluet]

The LocalRef optimization pass has a pre-transformation that moves any global 'a ref objects that are used in exactly one function, into the using function, so that it has an opportunity to be localized. However, if the ref is not turned into a local, then it is not moved back to a global.

[MatthewFluet]

With this observation about safe-for-space, I'm not understanding why there should ever be a non-empty globalObjptr[] array. In a self-compile, there are 26.

One contribution is that IntInf constants are not made into statics.

[MatthewFluet]

Draft merge commit message

Static allocation/initialization of objects in backend

The main benefits are that code size and compile time are improved across the board, particularly for larger programs. Runtime sometimes improves, but should only affect programs which had hot code accessing globals, as it removes one level of indirection. Garbage collections might be marginally faster, as globals are now mostly skipped.

Statically allocated and initialized objects are created in the main .c file, where they will be placed in the data segment of the executable:

const struct {Word64 meta_0; Word64 meta_1; Word64 meta_2; Word8 data[9];}
static_20 = {(Word64)(0x0ull), (Word64)(0x9ull), (Word64)(0x7ull), "addrinuse"};
const struct {Word64 meta_0; Word32 data_0; Word32 data_1; Pointer data_2; }
static_21 = {(Word64)(0x29ull), (Word32)(0x62ull), (Word32)(0x0ull), ((Pointer)(&static_20) + 24)};

Note that these are proper ML objects, with metadata and data. References to statically allocated objects are via pointers to the first data field (e.g., &static20 + 24). Note also that WordXVector (e.g., strings) are a special case of statically allocated and initialized objects. Statically allocated and initialized objects can be both immutable and mutable, although the latter should be restricted to objects with non-Objptr mutable fields.

A special case of statically allocated objects are arrays, whose contents will be dynamically initialized by the mutator. These are also created in the main .c file, but are placed in the bss segment of the executable (decreasing the size of the executable) and proper metadata is written by initialization code:

struct {Word64 meta_0; Word64 meta_1; Word64 meta_2; Word8 data[800000];}
static_26;
struct {Word64 meta_0; Word64 meta_1; Word64 meta_2; Word8 data[0];}
static_31;

static void static_Init() {
    memcpy (&static_26, &((struct {Word64 meta_0; Word64 meta_1; Word64 meta_2}){(Word64)(0x0ull), (Word64)(0x186A0ull), (Word64)(0x11ull)}), 24);
    memcpy (&static_31, &((struct {Word64 meta_0; Word64 meta_1; Word64 meta_2}){(Word64)(0x0ull), (Word64)(0x0ull), (Word64)(0x13ull)}), 24);
};

Finally, dynamically allocated but statically initialized objects have their initialization data in the main .c file along with information to copy that data to the initial dynamic heap during initWorld:

const static struct {Word64 meta_0; Word64 data_0; }
static_9819 = {(Word64)(0x79Dull), (Word64)(0x1ull)};
const static struct {Word64 meta_0; Word64 data_0; }
static_9820 = {(Word64)(0x79Dull), (Word64)(0x1ull)};

static struct GC_objectInit objectInits[] = {
    { 11, 8, 16, ((Pointer) &static_9819) },
    { 12, 8, 16, ((Pointer) &static_9820) },
    ...
}

By default (with -static-init-objects staticAllocOnly), no such objects are created.

With -static-init-objects all, global objects with Objptr mutable fields would be dynamically allocated but statically initialized. But, such global objects are rare. For example, a (int * int) ref could be space-safely globalized and would be an object with a mutable Objptr field. However, it is also likely that such a tuple would be RefFlattened. With -globalize-small-type 4 (see #288 and 752467c), an (int * int, int * int) either ref could be globalized and represented as an object with a mutable Objptr field. Similarly, an IntInf.int ref can also be globalized and would be represented as an object with a mutable Objptr field.

With -static-alloc-objects false -static-init-objects all, all global objects will be dynamically allocated but statically initialized (and no global objects will be statically allocated). Similarly, with -static-alloc-wordvector-consts false, string constants will be dynamically allocated but statically initialized; this corresponds to the previous MLton behavior with respect to string constants.

A number of controls have been added to control static allocation/initialization:

• -static-alloc-internal-ptrs {static|all|none}

  Controls which kinds of objects can be statically allocated:

  • static: only objects with all fields either immutable or non-Objptr
  • none: only objects with no fields
  • all: all objects

  The all setting is incompatible with the current GC for two reasons. First, statically allocated objects are not traced by the GC; a statically-allocated object that is updated with an Objptr to an object in the heap should be considered a root. Second, a statically-allocated object that is updated with an Objptr would trigger a card marking, but the address of a statically-allocated object would not map to a valid card slot.

• -static-alloc-wordvector-consts {true|false}

  Controls whether or not WordXVector constants are converted to statics (with ImmStatic location) at Ssa2ToRssa.

• -static-init-arrays {true|false}

  Controls whether or not Array_alloc primitives are converted to statics (with MutStatic or Heap location) at Ssa2ToRssa.

• -static-alloc-arrays {true|false}

  Controls whether or not Array_alloc primitives that can be statically initialized are forced to Heap location.

• -static-init-objects {none|staticAllocOnly|all}

  Controls whether or not Object expressions are converted to statics at Ssa2ToRssa. If staticAllocOnly, then an object that would be converted to a static with Heap location is not converted to a static.

• -static-alloc-objects {true|false}

  Controls whether or not Object expressions that can be statically initialized are forced to Heap location.