This file includes short notes related to the current version of the compiler.

Conversion to SSA

1- The body of a while loop is not converted to SSA.

2- Variables defined inside true branch or false branch of a conditional statement may be defined in the other branch of the same conditional statement, too. This is based on the observation that two branches of one conditional statement are the same, except that one is optimized.

Optimize Pragma

1- The location of Optimize pragma inside the program does not change its semantics.

2- The code that is optimized by the pragma starts from the first line after the last definition of the optimized variable through end of the program.

While Loop and Optimize interaction

1- If Optimize is called on a variable whose last definition is inside the body of a loop, the corresponding if-then-else will start right after that while loop.

2- Optimize cannot be used for a loop variable.

Performance of the Compiler

1- Currently the a seriously time consuming operation in the compiler is copy.deepcopy(). All invocations of copy.deepcopy() must be check and all unnecessary ones must be removed.

Problems in the Current Architecture

1- A common subexpression elimination must be called after the end of dead code elimination to remove common subexpressions introduced by remove_copies()

2- Symbol tables requires better design. Sometimes we need to collapse while loop and do not count it's body, and sometime we need to expand this. Also currently we construct symbol table twice in the code. One for SSA and one for basic block creation. We need to construct the symbol table just once, so that it responds to both queries.

3- The code in normalize does three tasks: conversion to three address code, simplification using boolean algebra and common subexpression elimination. The three must be separated. At least the last two should become independent components.

4- We have an input language and an output language. Since input language is high level, it hides some details of the output language. A specific example is carry variables. There are two problems with the current approach.

4-1 The level of abstraction is lowered in the compiler implicitly during Translation pass. It should be clear in which passes of the compiler the level of abstraction is lowered.
4-2 The classes bitexpr.Add and bitexpr.Sub has been designed with C output in mind. They should not be target dependent as in the optimizer, we want to stay independent of the output language. One may require that class Add distinguishes carry in and carry out variables.
4-3 Right now we have two different implementations of Advance, one uses addition and the other one does not. The current architecture of the compiler assumes that the implementation of Advance is based on addition. One may ask require the architecture of the compiler to have this property. If we come up with a new implementation for a bitutil function, the compiler can be configured such that it generates output code that uses the new implementation.

Last modified 9 years ago Last modified on Mar 12, 2010, 11:28:20 AM