Project 2 : SSA

Project 2: SSA

Due Date: Thursday, February 26, 2009

Programs should be submitted through csnet.cs.tamu.edu by the announced time. Submissions should be in the form of a single file named project2_UIN.tar.gz file (where UIN is your UIN number) containing the relevant source code and a README file explaining your approach (see Creating .tar.gz File below on how to create and submit this file.)

Introduction

In this project, you will transform the program into Static Single Assignment (SSA) form. Once this is completed, you will transform the code back into regular FORTRAN format. The algorithms you will implement in Project 2 are described in Chapter 6 of the Wolfe book. To simplify design, the project is broken into three smaller parts :

Phi/Upsilon Node Insertion (30%)
Variable Renaming (50 %)
Dessa (20%)

Input and Output

The input/output process will be the same as previous projects.

Program Design

Switches

All the routines for SSA should be controlled by switches. For these passes you will use the following switches :

ssa          1  transform into SSA form (0=dont,1=do)
p_ssa        1  print after SSA pass (0=dont, 1=do)
dessa        1  revert from SSA form (0=dont,1=do)
p_dessa      1  print after deSSA pass (0=dont, 1=FORTRAN,2=detailed)

These values are the default as specified in the file switches in your work directory (do not remove this file since it is a symbolic link to the default switchfile -- copy it to another file and specify that filename with the -f option when running mini_polaris.)

The driver program will only call the routines in these passes if ssa is 1. The print switches will only be examined if the relevant passes are turned on.

SSA Pass

Interface

The SSA pass should be implemented in the ~/minipolaris/ssa directory. The file ssa.h shows the prototypes of the functions called from the driver program

void ssa(ProgramUnit & pgm);
void dessa(ProgramUnit & pgm);

This is a simple pass which takes one program unit as input, transforms any relevant statements inside, and completes, returning nothing. If you create other source files, you should add them to these two lines so they will be compiled and linked into the final program.

Algorithm Design

ssa() is given a Program Unit on which to work. It need not output any information itself. You should follow the algorithms given in Figure 6.5 (p. 175) and Figure 6.7 (p. 178) of Wolfe.

dessa() is given a Program Unit which has already been transformed into SSA, and should remove all SSA forms from the code, i.e. remove all PHI and UPSILON functions, as well as any variable renaming.

The following convention should be used :

For variable subscripts, use var@# where var is the variable and # is the subscript number. For example, X₁would be indicated as X@1 in Polaris.

For the functions phi and upsilon (the book uses the appropriate Greek characters) you will simply write it as a FORTRAN function of the name PHI or UPSILON, respectively. The arguments will be chain vector elements, in order. You should express it as an assignment, i.e.

      phi(A)_4~>3,6

becomes

A@4 = PHI(A@3, A@6)

Compiling

You can re-compile your files from within the ssa directory as long as you have compiled mini_polaris once. In another word; mini_polaris has already been generated.

If you have not compiled out mini_polaris yet, change to your work directory and do a make from there.

If you make some changes and want to recompile, just type make at the ssa directory. Or, if you want to do it from the top-level makefile, you should do (suppose you are at the ssa directory)

rm libssa_pkg.so.1

cd ~/minipolaris

make

Creating .tar.gz File

The files necessary for submission should be all source code (.cc and .h), make.depend and Makefile in the ssa directory

Department of Computer Science and Engineering | Dwight Look College of Engineering | Texas A&M University
Privacy statement: Computer Science and Engineering Engineering TAMU