Introducing the inlining phase

[takagi]

The inlining phase is to be introduced within the compiler phases for optimization.

[takagi]

For now, locally defined functions are inlined on f1f4aae. Inlined expressions will be α-converted again.

In addition, following changes are applied:

• in K-normalization, use an environment to find undefined variables
• in α-conversion, return variables not found in its environment as they are, for convenience in α-conversion during inlining again

With following restrictions:

• top level functions are not inlined
• mutual recursive loops are not broken
• no repetitive optimization
• no way to decide if a function should be inlined

[takagi]

For now, top-level defined functions are inlined on dc7f2fb.

Approach:

• pass top-level defined functions to inlining phase
• when passed, the functions need to be compiled just before inlining phase
• for that, let *program* have the functions compiled before inlining phase

With following restrictions:

• mutual recursive loops are not broken
• no repetitive optimization
• no way to decide if a function should be inlined

There are other approaches as following:

• program as a large expression: MinCaml
• program as a list of top-level bindings: Haskell

[takagi]

For now, repetitive optimization is enabled on 9435300.

Restrictions remained:

• mutual recursive loops are not broken
• no way to decide if a function should be inlined

[takagi]

Now, on 2daf70b, inlining top-level defined functions is based on GHC's cross-module inlining in its approach.

GHC's cross-module inlining does the following:

• when compiling module M, writes an "interface file" M.hi that includes top-level definitions in M
• after that, when compiling module A that imports M GHC slurps M.hi and inlines calls in A to M's exports