Improvement for evaluation stack handling.

[kekyo]

    int32_t stack0_0;
    intptr_t stack0_1;
    int32_t stack1_0;
    intptr_t stack1_1;
    int32_t stack2_0;

    // Body...

Combined to:

    union {
        int32_t slot0;
        intptr_t slot1;
    } stack0;
    union {
        int32_t slot0;
        intptr_t slot1;
    } stack1;
    int32_t stack2_0;

    // Body...

If contained OR:

    union {
        int32_t slot0;
        intptr_t slot1;
    } stack0;
    union {
        int32_t slot0;
        intptr_t slot1;
    } stack1;
    System_String* stack1_2;   // Have to NOT combined into stack1.
    int32_t stack2_0;

    // Body...

Because GC's required trackable for OR.

Pros:

• Reduce stack allocation.

Cons:

• Bad readability.
• C compiler maybe can't sense usage for variables, so will not draw optimize.

[kekyo]

fc0e82dfca0194c6fd4b1b71f148a49d1d4b102c

Finally, I changed stack storage from one by one definition to aggregated at one structure for objrefs. For example (TypeSystems/DelegateTypes/Base_Int32ToString):

    struct /* IL2C_EXECUTION_FRAME */
    {
        uint8_t objRefCount__;
        uint8_t objRefRefCount__;
        IL2C_EXECUTION_FRAME* pNext__;
        System_String* local0__;
        System_String* stack0_1__;
        System_String* stack1_0__;
        IL2C_TypeSystems_DelegateTypesWithVirtual_Base* stack2_0__;
        System_String* stack2_2__;
    } frame__ = { 5, 0 };

    il2c_link_execution_frame(&frame__);

The frame__ is unnamed structure for the new EXECUTION_FRAME format. It contains the local variables and evaluation stacks for objrefs.

It has advantage for:

• Standard C initializer expression works efficiently,
• We don't need setup for objref's references.
• We will be able to handle filter exceptions. (but we need more improvement)

The disadvantages are:

• We have to add referrer the objref symbol with frame__. prefix. (debugger can't resolve...)

"Unioning" cancelled. Because the union members are maybe disable the optimization target for C compiler.