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 f1f4aaebdc39e79d46a17099e38fd2c85f8267a4. 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 dc7f2fb03e42ebb886f98531a9d5457eedab5d21.

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 9435300d44f12e4e7ab541f5f076e1244385e5ea.

Restrictions remained:

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

[takagi]

Now, on 2daf70b6801d0bd5746fff913b6a94edf90cdf78, 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