Browse Source

Initial revision

ceriel 37 years ago
parent
commit
004f017550
30 changed files with 3903 additions and 0 deletions
  1. 57 0
      doc/ego/ic/ic1
  2. 146 0
      doc/ego/ic/ic2
  3. 414 0
      doc/ego/ic/ic3
  4. 80 0
      doc/ego/ic/ic4
  5. 163 0
      doc/ego/ic/ic5
  6. 112 0
      doc/ego/il/il1
  7. 93 0
      doc/ego/il/il2
  8. 164 0
      doc/ego/il/il3
  9. 132 0
      doc/ego/il/il4
  10. 440 0
      doc/ego/il/il5
  11. 27 0
      doc/ego/il/il6
  12. 7 0
      doc/ego/intro/head
  13. 79 0
      doc/ego/intro/intro1
  14. 3 0
      doc/ego/intro/tail
  15. 95 0
      doc/ego/lv/lv1
  16. 371 0
      doc/ego/ov/ov1
  17. 33 0
      doc/ego/ra/ra1
  18. 139 0
      doc/ego/ra/ra2
  19. 383 0
      doc/ego/ra/ra3
  20. 28 0
      doc/ego/ra/ra4
  21. 171 0
      doc/ego/sp/sp1
  22. 44 0
      doc/ego/sr/sr1
  23. 217 0
      doc/ego/sr/sr2
  24. 232 0
      doc/ego/sr/sr3
  25. 28 0
      doc/ego/sr/sr4
  26. 58 0
      doc/ego/ud/ud1
  27. 64 0
      doc/ego/ud/ud2
  28. 26 0
      doc/ego/ud/ud3
  29. 78 0
      doc/ego/ud/ud4
  30. 19 0
      doc/ego/ud/ud5

+ 57 - 0
doc/ego/ic/ic1

@@ -0,0 +1,57 @@
+.bp
+.NH
+The Intermediate Code and the IC phase
+.PP
+In this chapter the intermediate code of the EM global optimizer
+will be defined.
+The 'Intermediate Code construction' phase (IC),
+which builds the initial intermediate code from
+EM Compact Assembly Language,
+will be described.
+.NH 2
+Introduction
+.PP
+The EM global optimizer is a multi pass program,
+hence there is a need for an intermediate code.
+Usually, programs in the Amsterdam Compiler Kit use the
+Compact Assembly Language format
+.[~[
+keizer architecture
+.], section 11.2]
+for this purpose.
+Although this code has some convenient features,
+such as being compact,
+it is quite unsuitable in our case,
+because of a number of reasons.
+At first, the code lacks global information
+about whole procedures or whole basic blocks.
+Second, it uses identifiers ('names') to bind
+defining and applied occurrences of
+procedures, data labels and instruction labels.
+Although this is usual in high level programming
+languages, it is awkward in an intermediate code
+that must be read many times.
+Each pass of the optimizer would have
+to incorporate an identifier look-up mechanism
+to associate a defining occurrence with each
+applied occurrence of an identifier.
+Finally, EM programs are used to declare blocks of bytes,
+rather than variables. A 'hol 6' instruction may be used to
+declare three 2-byte variables.
+Clearly, the optimizer wants to deal with variables, and
+not with rows of bytes.
+.PP
+To overcome these problems, we have developed a new
+intermediate code.
+This code does not merely consist of the EM instructions,
+but also contains global information in the
+form of tables and graphs.
+Before describing the intermediate code we will
+first leap aside to outline
+the problems one generally encounters
+when trying to store complex data structures such as
+graphs outside the program, i.e. in a file.
+We trust this will enhance the
+comprehensibility of the
+intermediate code definition and the design and implementation
+of the IC phase.

+ 146 - 0
doc/ego/ic/ic2

@@ -0,0 +1,146 @@
+.NH 2
+Representation of complex data structures in a sequential file
+.PP
+Most programmers are quite used to deal with
+complex data structures, such as
+arrays, graphs and trees.
+There are some particular problems that occur
+when storing such a data structure
+in a sequential file.
+We call data that is kept in
+main memory
+.UL internal
+,as opposed to
+.UL external
+data
+that is kept in a file outside the program.
+.sp
+We assume a simple data structure of a
+scalar type (integer, floating point number)
+has some known external representation.
+An
+.UL array
+having elements of a scalar type can be represented
+externally easily, by successively
+representing its elements.
+The external representation may be preceded by a
+number, giving the length of the array.
+Now, consider a linear, singly linked list,
+the elements of which look like:
+.DS
+record
+        data: scalar_type;
+        next: pointer_type;
+end;
+.DE
+It is significant to note that the "next"
+fields of the elements only have a meaning within
+main memory.
+The field contains the address of some location in
+main memory.
+If a list element is written to a file in
+some program,
+and read by another program,
+the element will be allocated at a different
+address in main memory.
+Hence this address value is completely
+useless outside the program.
+.sp
+One may represent the list by ignoring these "next" fields
+and storing the data items in the order they are linked.
+The "next" fields are represented \fIimplicitly\fR.
+When the file is read again,
+the same list can be reconstructed.
+In order to know where the external representation of the
+list ends,
+it may be useful to put the length of
+the list in front of it.
+.sp
+Note that arrays and linear lists have the
+same external representation.
+.PP
+A doubly linked, linear list,
+with elements of the type:
+.DS
+record
+        data: scalar_type;
+        next,
+        previous: pointer_type;
+end
+.DE
+can be represented in precisely the same way.
+Both the "next" and the "previous" fields are represented
+implicitly.
+.PP
+Next, consider a binary tree,
+the nodes of which have type:
+.DS
+record
+        data: scalar_type;
+        left,
+        right: pointer_type;
+end
+.DE
+Such a tree can be represented sequentially,
+by storing its nodes in some fixed order, e.g. prefix order.
+A special null data item may be used to
+denote a missing left or right son.
+For example, let the scalar type be integer,
+and let the null item be 0.
+Then the tree of fig. 3.1(a)
+can be represented as in fig. 3.1(b).
+.DS
+                        4
+
+                    9      12
+
+                12    3   4   6
+
+                     8  1  5 1
+
+Fig. 3.1(a) A binary tree
+
+
+4 9 12 0 0 3 8 0 0 1 0 0 12 4 0 5 0 0 6 1 0 0 0
+
+Fig. 3.1(b) Its sequential representation
+.DE
+We are still able to represent the pointer fields ("left"
+and "right") implicitly.
+.PP
+Finally, consider a general
+.UL graph
+, where each node has a "data" field and
+pointer fields,
+with no restriction on where they may point to.
+Now we're at the end of our tale.
+There is no way to represent the pointers implicitly,
+like we did with lists and trees.
+In order to represent them explicitly,
+we use the following scheme.
+Every node gets an extra field,
+containing some unique number that identifies the node.
+We call this number its
+.UL id.
+A pointer is represented externally as the id of the node
+it points to.
+When reading the file we use a table that maps
+an id to the address of its node.
+In general this table will not be completely filled in
+until we have read the entire external representation of
+the graph and allocated internal memory locations for
+every node.
+Hence we cannot reconstruct the graph in one scan.
+That is, there may be some pointers from node A to B,
+where B is placed after A in the sequential file than A.
+When we read the node of A we cannot map the id of B
+to the address of node B,
+as we have not yet allocated node B.
+We can overcome this problem if the size
+of every node is known in advance.
+In this case we can allocate memory for a node
+on first reference.
+Else, the mapping from id to pointer
+cannot be done while reading nodes.
+The mapping can be done either in an extra scan
+or at every reference to the node.

+ 414 - 0
doc/ego/ic/ic3

@@ -0,0 +1,414 @@
+.NH 2
+Definition of the intermediate code
+.PP
+The intermediate code of the optimizer consists
+of several components:
+.IP -
+the object table
+.IP -
+the procedure table
+.IP -
+the em code
+.IP -
+the control flow graphs
+.IP -
+the loop table
+.LP -
+.PP
+These components are described in
+the next sections.
+The syntactic structure of every component
+is described by a set of context free syntax rules,
+with the following conventions:
+.DS
+x               a non-terminal symbol
+A               a terminal symbol (in capitals)
+x: a b c;       a grammar rule
+a | b           a or b
+(a)+            1 or more occurrences of a
+{a}             0 or more occurrences of a
+.DE
+.NH 3
+The object table
+.PP
+EM programs declare blocks of bytes rather than (global) variables.
+A typical program may declare 'HOL 7780'
+to allocate space for 8 I/O buffers,
+2 large arrays and 10 scalar variables.
+The optimizer wants to deal with
+.UL objects
+like variables, buffers and arrays
+and certainly not with huge numbers of bytes.
+Therefore the intermediate code contains information
+about which global objects are used.
+This information can be obtained from an EM program
+by just looking at the operands of instruction
+such as LOE, LAE, LDE, STE, SDE, INE, DEE and ZRE.
+.PP
+The object table consists of a list of
+.UL datablock
+entries.
+Each such entry represents a declaration like HOL, BSS,
+CON or ROM.
+There are five kinds of datablock entries.
+The fifth kind,
+UNKNOWN, denotes a declaration in a
+separately compiled file that is not made
+available to the optimizer.
+Each datablock entry contains the type of the block,
+its size, and a description of the objects that
+belong to it.
+If it is a rom,
+it also contains a list of values given
+as arguments to the rom instruction,
+provided that this list contains only integer numbers.
+An object has an offset (within its datablock)
+and a size.
+The size need not always be determinable.
+Both datablock and object contain a unique
+identifying number
+(see previous section for their use).
+.DS
+.UL syntax
+  object_table:
+                {datablock} ;
+  datablock:
+                D_ID            -- unique identifying number
+                PSEUDO          -- one of ROM,CON,BSS,HOL,UNKNOWN
+                SIZE            -- # bytes declared
+                FLAGS
+                {value}         -- contents of rom
+                {object} ;      -- objects of the datablock
+  object:
+                O_ID            -- unique identifying number
+                OFFSET          -- offset within the datablock
+                SIZE ;          -- size of the object in bytes
+  value:
+                argument ;
+.DE
+A data block has only one flag: "external", indicating
+whether the data label is externally visible.
+The syntax for "argument" will be given later on
+(see em_text).
+.NH 3
+The procedure table
+.PP
+The procedure table contains global information
+about all procedures that are made available
+to the optimizer
+and that are needed by the EM program.
+(Library units may not be needed, see section 3.5).
+The table has one entry for
+every procedure.
+.DS
+.UL syntax
+  procedure_table:
+                {procedure}
+  procedure:
+                P_ID            -- unique identifying number
+                #LABELS         -- number of instruction labels
+                #LOCALS         -- number of bytes for locals 
+		#FORMALS        -- number of bytes for formals
+                FLAGS           -- flag bits
+                calling         -- procedures called by this one
+                change          -- info about global variables changed
+                use ;           -- info about global variables used
+  calling:
+                {P_ID} ;        -- procedures called
+  change:
+                ext             -- external variables changed
+                FLAGS ;
+  use:
+                FLAGS ;
+  ext:
+                {O_ID} ;        -- a set of objects
+.DE
+.PP
+The number of bytes of formal parameters accessed by
+a procedure is determined by the front ends and
+passed via a message (parameter message) to the optimizer.
+If the front end is not able to determine this number
+(e.g. the parameter may be an array of dynamic size or
+the procedure may have a variable number of arguments) the attribute
+contains the value 'UNKNOWN_SIZE'.
+.sp 0
+A procedure has the following flags:
+.IP -
+external: true if the proc. is externally visible
+.IP -
+bodyseen: true if its code is available as EM text
+.IP -
+calunknown: true if it calls a procedure that has its bodyseen
+flag not set
+.IP -
+environ: true if it uses or changes a (non-global) variable in
+a lexically enclosing procedure
+.IP -
+lpi: true if is used as operand of an lpi instruction, so
+it may be called indirect
+.LP
+The change and use attributes both have one flag: "indirect",
+indicating whether the procedure does a 'use indirect'
+or a 'store indirect' (indirect means through a pointer).
+.NH 3
+The EM text
+.PP
+The EM text contains the EM instructions.
+Every EM instruction has an operation code (opcode)
+and 0 or 1 operands.
+EM pseudo instructions can have more than
+1 operand.
+The opcode is just a small (8 bit) integer.
+.sp
+There are several kinds of operands, which we will
+refer to as
+.UL types.
+Many EM instructions can have more than one type of operand.
+The types and their encodings in Compact Assembly Language
+are discussed extensively in.
+.[~[
+keizer architecture 
+.], section 11.2]
+Of special interest is the way numeric values
+are represented.
+Of prime importance is the machine independency of
+the representation.
+Ultimately, one could store every integer
+just as a string of the characters '0' to '9'.
+As doing arithmetic on strings is awkward,
+Compact Assembly Language allows several alternatives.
+The main idea is to look at the value of the integer.
+Integers that fit in 16, 32 or 64 bits are
+represented as a row of resp. 2, 4 and 8 bytes,
+preceded by an indication of how many bytes are used.
+Longer integers are represented as strings;
+this is only allowed within pseudo instructions, however.
+This concept works very well for target machines
+with reasonable word sizes.
+At present, most ACK software cannot be used for word sizes
+higher than 32 bits,
+although the handles for using larger word sizes are
+present in the design of the EM code.
+In the intermediate code we essentially use the
+same ideas.
+We allow three representations of integers.
+.IP -
+integers that fit in a short are represented as a short
+.IP -
+integers that fit in a long but not in a short are represented
+as longs
+.IP -
+all remaining integers are represented as strings
+(only allowed in pseudos).
+.LP
+The terms short and long are defined in
+.[~[
+ritchie reference manual programming language
+.], section 4]
+and depend only on the source machine
+(i.e. the machine on which ACK runs),
+not on the target machines.
+For historical reasons a long will often be called an
+.UL offset.
+.PP
+Operands can also be instruction labels,
+objects or procedures.
+Instruction labels are denoted by a
+.UL label
+.UL identifier,
+which can be distinguished from a normal identifier.
+.sp
+The operand of a pseudo instruction can be a list of
+.UL arguments.
+Arguments can have the same type as operands, except
+for the type short, which is not used for arguments.
+Furthermore, an argument can be a string or
+a string representation of a signed integer, unsigned integer
+or floating point number.
+If the number of arguments is not fully determined by
+the pseudo instruction (e.g. a ROM pseudo can have any number
+of arguments), then the list is terminated by a special
+argument of type CEND.
+.DS
+.UL syntax
+  em_text:
+                {line} ;
+  line:
+                INSTR           -- opcode
+                OPTYPE          -- operand type
+                operand ;
+  operand:
+                empty |         -- OPTYPE = NO
+                SHORT |         -- OPTYPE = SHORT
+                OFFSET |        -- OPTYPE = OFFSET
+                LAB_ID |        -- OPTYPE = INSTRLAB
+                O_ID |          -- OPTYPE = OBJECT
+                P_ID |          -- OPTYPE = PROCEDURE
+                {argument} ;    -- OPTYPE = LIST
+  argument:
+                ARGTYPE
+                arg ;
+  arg:
+                empty |         -- ARGTYPE = CEND
+                OFFSET |
+                LAB_ID |
+                O_ID |
+                P_ID |
+                string |        -- ARGTYPE = STRING
+                const ;         -- ARGTYPE = ICON,UCON or FCON
+  string:
+                LENGTH          -- number of characters
+                {CHARACTER} ;
+  const:
+                SIZE            -- number of bytes
+                string ;        -- string representation of (un)signed
+                                -- or floating point constant
+.DE
+.NH 3
+The control flow graphs
+.PP
+Each procedure can be divided
+into a number of basic blocks.
+A basic block is a piece of code with
+no jumps in, except at the beginning,
+and no jumps out, except at the end.
+.PP
+Every basic block has a set of
+.UL successors,
+which are basic blocks that can follow it immediately in
+the dynamic execution sequence.
+The
+.UL predecessors
+are the basic blocks of which this one
+is a successor.
+The successor and predecessor attributes
+of all basic blocks of a single procedure
+are said to form the
+.UL control
+.UL flow
+.UL graph
+of that procedure.
+.PP
+Another important attribute is the
+.UL immediate
+.UL dominator.
+A basic block B dominates a block C if
+every path in the graph from the procedure entry block
+to C goes through B.
+The immediate dominator of C is the closest dominator
+of C on any path from the entry block.
+(Note that the dominator relation is transitive,
+so the immediate dominator is well defined.)
+.PP
+A basic block also has an attribute containing
+the identifiers of every
+.UL loop
+that the block belongs to (see next section for loops).
+.DS
+.UL syntax
+  control_flow_graph:
+                {basic_block} ;
+  basic_block:
+                B_ID            -- unique identifying number
+                #INSTR          -- number of EM instructions
+                succ
+                pred
+                idom            -- immediate dominator
+                loops           -- set of loops
+		FLAGS ;         -- flag bits
+  succ:
+                {B_ID} ;
+  pred:
+                {B_ID} ;
+  idom:
+                B_ID ;
+  loops:
+                {LP_ID} ;
+.DE
+The flag bits can have the values 'firm' and 'strong',
+which are explained below.
+.NH 3
+The loop tables
+.PP
+Every procedure has an associated
+.UL loop
+.UL table
+containing information about all the loops
+in the procedure.
+Loops can be detected by a close inspection of
+the control flow graph.
+The main idea is to look for two basic blocks,
+B and C, for which the following holds:
+.IP -
+B is a successor of C
+.IP -
+B is a dominator of C
+.LP
+B is called the loop
+.UL entry
+and C is called the loop
+.UL end.
+Intuitively, C contains a jump backwards to
+the beginning of the loop (B).
+.PP
+A loop L1 is said to be
+.UL nested
+within loop L2 if all basic blocks of L1
+are also part of L2.
+It is important to note that loops could
+originally be written as a well structured for -or
+while loop or as a messy goto loop.
+Hence loops may partly overlap without one
+being nested inside the other.
+The
+.UL nesting
+.UL level
+of a loop is the number of loops in
+which it is nested (so it is 0 for
+an outermost loop).
+The details of loop detection will be discussed later.
+.PP
+It is often desirable to know whether a
+basic block gets executed during every iteration
+of a loop.
+This leads to the following definitions:
+.IP -
+A basic block B of a loop L is said to be a \fIfirm\fR block
+of L if B is executed on all successive iterations of L,
+with the only possible exception of the last iteration.
+.IP -
+A basic block B of a loop L is said to be a \fIstrong\fR block
+of L if B is executed on all successive iterations of L.
+.LP
+Note that a strong block is also a firm block.
+If a block is part of a conditional statement, it is neither
+strong nor firm, as it may be skipped during some iterations
+(see Fig. 3.2).
+.DS
+loop
+       if cond1 then
+	      ... -- this code will not
+		  -- result in a firm or strong block
+       end if;
+       ...  -- strong (always executed)
+       exit when cond2;
+       ...  -- firm (not executed on
+            -- last iteration).
+end loop;
+
+Fig. 3.2 Example of firm and strong block
+.DE
+.DS
+.UL syntax
+  looptable:
+                {loop} ;
+  loop:
+                LP_ID           -- unique identifying number
+                LEVEL           -- loop nesting level
+                entry           -- loop entry block
+                end ;
+  entry:
+                B_ID ;
+  end:
+                B_ID ;
+.DE

+ 80 - 0
doc/ego/ic/ic4

@@ -0,0 +1,80 @@
+.NH 2
+External representation of the intermediate code
+.PP
+The syntax of the intermediate code was given
+in the previous section.
+In this section we will make some remarks about
+the representation of the code in sequential files.
+.sp
+We use sequential files in order to avoid
+the bookkeeping of complex file indices.
+As a consequence of this decision
+we can't store all components
+of the intermediate code
+in one file.
+If a phase wishes to change some attribute
+of a procedure,
+or wants to add or delete entire procedures
+(inline substitution may do the latter),
+the procedure table will only be fully updated
+after the entire EM text has been scanned.
+Yet, the next phase undoubtedly wants
+to read the procedure table before it
+starts working on the EM text.
+Hence there is an ordering problem, which
+can be solved easily by putting the
+procedure table in a separate file.
+Similarly, the data block table is kept
+in a file of its own.
+.PP
+The control flow graphs (CFGs) could be mixed
+with the EM text.
+Rather, we have chosen to put them
+in a separate file too.
+The control flow graph file should be regarded as a
+file that imposes some structure on the EM-text file,
+just as an overhead sheet containing a picture
+of a Flow Chart may be put on an overhead sheet
+containing statements.
+The loop tables are also put in the CFG file.
+A loop imposes an extra structure on the
+CFGs and hence on the EM text.
+So there are four files:
+.IP -
+the EM-text file
+.IP -
+the procedure table file
+.IP -
+the object table file
+.IP -
+the CFG and loop tables file
+.LP
+Every table is preceded by its length, in order to
+tell where it ends.
+The CFG file also contains the number of instructions of
+every basic block,
+indicating which part of the EM text belongs
+to that block.
+.DS
+.UL syntax
+  intermediate_code:
+                object_table_file
+                proctable_file
+                em_text_file
+                cfg_file ;
+  object_table_file:
+                LENGTH          -- number of objects
+                object_table ;
+  proctable_file:
+                LENGTH          -- number of procedures
+                procedure_table ;
+  em_text_file:
+                em_text ;
+  cfg_file:
+                {per_proc} ;    -- one for every procedure
+  per_proc:
+                BLENGTH         -- number of basic blocks
+                LLENGTH         -- number of loops
+                control_flow_graph
+                looptable ;
+.DE

+ 163 - 0
doc/ego/ic/ic5

@@ -0,0 +1,163 @@
+.NH 2
+The Intermediate Code construction phase
+.PP
+The first phase of the global optimizer,
+called
+.UL IC,
+constructs a major part of the intermediate code.
+To be specific, it produces:
+.IP -
+the EM text
+.IP -
+the object table
+.IP -
+part of the procedure table
+.LP
+The calling, change and use attributes of a procedure
+and all its flags except the external and bodyseen flags
+are computed by the next phase (Control Flow phase).
+.PP
+As explained before,
+the intermediate code does not contain
+any names of variables or procedures.
+The normal identifiers are replaced by identifying
+numbers.
+Yet, the output of the global optimizer must
+contain normal identifiers, as this
+output is in Compact Assembly Language format.
+We certainly want all externally visible names
+to be the same in the input as in the output,
+because the optimized EM module may be a library unit,
+used by other modules.
+IC dumps the names of all procedures and data labels
+on two files:
+.IP -
+the procedure dump file, containing tuples (P_ID, procedure name)
+.IP -
+the data dump file, containing tuples (D_ID, data label name)
+.LP
+The names of instruction labels are not dumped,
+as they are not visible outside the procedure
+in which they are defined.
+.PP
+The input to IC consists of one or more files.
+Each file is either an EM module in Compact Assembly Language
+format, or a Unix archive file (library) containing such modules.
+IC only extracts those modules from a library that are
+needed somehow, just as a linker does.
+It is advisable to present as much code
+of the EM program as possible to the optimizer,
+although it is not required to present the whole program.
+If a procedure is called somewhere in the EM text,
+but its body (text) is not included in the input,
+its bodyseen flag in the procedure table will still
+be off.
+Whenever such a procedure is called,
+we assume the worst case for everything;
+it will change and use all variables it has access to,
+it will call every procedure etc.
+.sp
+Similarly, if a data label is used
+but not defined, the PSEUDO attribute in its data block
+will be set to UNKNOWN.
+.NH 3
+Implementation
+.PP
+Part of the code for the EM Peephole Optimizer
+.[
+staveren peephole toplass
+.]
+has been used for IC.
+Especially the routines that read and unravel
+Compact Assembly Language and the identifier
+lookup mechanism have been used.
+New code was added to recognize objects,
+build the object and procedure tables and to
+output the intermediate code.
+.PP
+IC uses singly linked linear lists for both the
+procedure and object table.
+Hence there are no limits on the size of such
+a table (except for the trivial fact that it must fit
+in main memory).
+Both tables are outputted after all EM code has
+been processed.
+IC reads the EM text of one entire procedure
+at a time,
+processes it and appends the modified code to
+the EM text file.
+EM code is represented internally as a doubly linked linear
+list of EM instructions.
+.PP
+Objects are recognized by looking at the operands
+of instructions that reference global data.
+If we come across the instructions:
+.DS
+LDE X+6         -- Load Double External
+LAE X+20        -- Load Address External
+.DE
+we conclude that the data block
+preceded by the data label X contains an object
+at offset 6 of size twice the word size,
+and an object at offset 20 of unknown size.
+.sp
+A data block entry of the object table is allocated
+at the first reference to a data label.
+If this reference is a defining occurrence
+or a INA pseudo instruction,
+the label is not externally visible
+.[~[
+keizer architecture
+.], section 11.1.4.3]
+In this case, the external flag of the data block
+is turned off.
+If the first reference is an applied occurrence
+or a EXA pseudo instruction, the flag is set.
+We record this information, because the
+optimizer may change the order of defining and
+applied occurrences.
+The INA and EXA pseudos are removed from the EM text.
+They may be regenerated by the last phase
+of the optimizer.
+.sp
+Similar rules hold for the procedure table
+and the INP and EXP pseudos.
+.NH 3
+Source files of IC
+.PP
+The source files of IC consist
+of the files ic.c, ic.h and several packages.
+.UL ic.h
+contains type definitions, macros and
+variable declarations that may be used by
+ic.c and by every package.
+.UL ic.c
+contains the definitions of these variables,
+the procedure
+.UL main
+and some high level I/O routines used by main.
+.sp
+Every package xxx consists of two files.
+ic_xxx.h contains type definitions,
+macros, variable declarations and
+procedure declarations that may be used by
+every .c file that includes this .h file.
+The file ic_xxx.c provides the
+definitions of these variables and
+the implementation of the declared procedures.
+IC uses the following packages:
+.IP lookup: 18
+procedures that loop up procedure, data label
+and instruction label names; procedures to dump
+the procedure and data label names.
+.IP lib:
+one procedure that gets the next useful input module;
+while scanning archives, it skips unnecessary modules.
+.IP aux:
+several auxiliary routines.
+.IP io:
+low-level I/O routines that unravel the Compact
+Assembly Language.
+.IP put:
+routines that output the intermediate code
+.LP

+ 112 - 0
doc/ego/il/il1

@@ -0,0 +1,112 @@
+.bp
+.NH 1
+Inline substitution
+.NH 2
+Introduction
+.PP
+The Inline Substitution technique (IL)
+tries to decrease the overhead associated
+with procedure calls (invocations).
+During a procedure call, several actions
+must be undertaken to set up the right
+environment for the called procedure.
+.[
+johnson calling sequence
+.]
+On return from the procedure, most of these
+effects must be undone.
+This entire process introduces significant
+costs in execution time as well as
+in object code size.
+.PP
+The inline substitution technique replaces
+some of the calls by the modified body of
+the called procedure, hence eliminating
+the overhead.
+Furthermore, as the calling and called procedure
+are now integrated, they can be optimized
+together, using other techniques of the optimizer.
+This often leads to extra opportunities for
+optimization
+.[
+ball predicting effects
+.]
+.[
+carter code generation cacm
+.]
+.[
+scheifler inline cacm
+.]
+.PP
+An inline substitution of a call to a procedure P increases
+the size of the program, unless P is very small or P is
+called only once.
+In the latter case, P can be eliminated.
+In practice, procedures that are called only once occur
+quite frequently, due to the
+introduction of structured programming.
+(Carter
+.[
+carter umi ann arbor
+.]
+states that almost 50% of the Pascal procedures
+he analyzed were called just once).
+.PP
+Scheifler
+.[
+scheifler inline cacm
+.]
+has a more general view of inline substitution.
+In his model, the program under consideration is
+allowed to grow by a certain amount,
+i.e. code size is sacrificed to speed up the program.
+The above two cases are just special cases of
+his model, obtained by setting the size-change to
+(approximately) zero.
+He formulates the substitution problem as follows:
+.IP
+"Given a program, a subset of all invocations,
+a maximum program size, and a maximum procedure size,
+find a sequence of substitutions that minimizes
+the expected execution time."
+.LP
+Scheifler shows that this problem is NP-complete
+.[~[
+aho hopcroft ullman analysis algorithms
+.], chapter 10]
+by reduction to the Knapsack Problem.
+Heuristics will have to be used to find a near-optimal
+solution.
+.PP
+In the following chapters we will extend
+Scheifler's view and adapt it to the EM Global Optimizer.
+We will first describe the transformations that have
+to be applied to the EM text when a call is substituted
+in line.
+Next we will examine in which cases inline substitution
+is not possible or desirable.
+Heuristics will be developed for
+chosing a good sequence of substitutions.
+These heuristics make no demand on the user
+(such as making profiles
+.[
+scheifler inline cacm
+.]
+or giving pragmats
+.[~[
+ichbiah ada military standard
+.], section 6.3.2]),
+although the model could easily be extended
+to use such information.
+Finally, we will discuss the implementation
+of the IL phase of the optimizer.
+.PP
+We will often use the term inline expansion
+as a synonym of inline substitution.
+.sp 0
+The inverse technique of procedure abstraction
+(automatic subroutine generation)
+.[
+shaffer subroutine generation
+.]
+will not be discussed in this report.

+ 93 - 0
doc/ego/il/il2

@@ -0,0 +1,93 @@
+.NH 2
+Parameters and local variables.
+.PP
+In the EM calling sequence, the calling procedure
+pushes its parameters on the stack
+before doing the CAL.
+The called routine first saves some
+status information on the stack and then
+allocates space for its own locals
+(also on the stack).
+Usually, one special purpose register,
+the Local Base (LB) register,
+is used to access both the locals and the
+parameters.
+If memory is highly segmented,
+the stack frames of the caller and the callee
+may be allocated in different fragments;
+an extra Argument Base (AB) register is used
+in this case to access the actual parameters.
+See 4.2 of
+.[
+keizer architecture
+.]
+for further details.
+.PP
+If a procedure call is expanded in line,
+there are two problems:
+.IP 1. 3
+No stack frame will be allocated for the called procedure;
+we must find another place to put its locals.
+.IP 2.
+The LB register cannot be used to access the actual
+parameters;
+as the CAL instruction is deleted, the LB will
+still point to the local base of the \fIcalling\fR procedure.
+.LP
+The local variables of the called procedure will
+be put in the stack frame of the calling procedure,
+just after its own locals.
+The size of the stack frame of the
+calling procedure will be increased
+during its entire lifetime.
+Therefore our model will allow a
+limit to be set on the number of bytes
+for locals that the called procedure may have
+(see next section).
+.PP
+There are several alternatives to access the parameters.
+An actual parameter may be any auxiliary expression,
+which we will refer to as
+the \fIactual parameter expression\fR.
+The value of this expression is stored
+in a location on the stack (see above),
+the \fIparameter location\fR.
+.sp 0
+The alternatives for accessing parameters are:
+.IP -
+save the value of the stackpointer at the point of the CAL
+in a temporary variable X;
+this variable can be used to simulate the AB register,  i.e.
+parameter locations are accessed via an offset to
+the value of X.
+.IP -
+create a new temporary local variable T for
+the parameter (in the stack frame of the caller);
+every access to the parameter location must be changed
+into an access to T.
+.IP -
+do not evaluate the actual parameter expression before the call;
+instead, substitute this expression for every use of the
+parameter location.
+.LP
+The first method may be expensive if X is not
+put in a register.
+We will not use this method.
+The time required to evaluate and access the
+parameters when the second method is used
+will not differ much from the normal
+calling sequence (i.e. not in line call).
+It is not expensive, but there are no
+extra savings either.
+The third method is essentially the 'by name'
+parameter mechanism of Algol60.
+If the actual parameter is just a numeric constant,
+it is advantageous to use it.
+Yet, there are several circumstances
+under which it cannot or should not be used.
+We will deal with this in the next section.
+.sp 0
+In general we will use the third method,
+if it is possible and desirable.
+Such parameters will be called \fIin line parameters\fR.
+In all other cases we will use the second method.

+ 164 - 0
doc/ego/il/il3

@@ -0,0 +1,164 @@
+.NH 2
+Feasibility and desirability analysis
+.PP
+Feasibility and desirability analysis
+of in line substitution differ
+somewhat from most other techniques.
+Usually, much effort is needed to find
+a feasible opportunity for optimization
+(e.g. a redundant subexpression).
+Desirability analysis then checks
+if it is really advantageous to do
+the optimization.
+For IL, opportunities are easy to find.
+To see if an in line expansion is
+desirable will not be hard either.
+Yet, the main problem is to find the most
+desirable ones.
+We will deal with this problem later and
+we will first attend feasibility and
+desirability analysis.
+.PP
+There are several reasons why a procedure invocation
+cannot or should not be expanded in line.
+.sp
+A call to a procedure P cannot be expanded in line
+in any of the following cases:
+.IP 1. 3
+The body of P is not available as EM text.
+Clearly, there is no way to do the substitution.
+.IP 2.
+P, or any procedure called by P (transitively),
+follows the chain of statically enclosing
+procedures (via a LXL or LXA instruction)
+or follows the chain of dynamically enclosing
+procedures (via a DCH).
+If the call were expanded in line,
+one level would be removed from the chains,
+leading to total chaos.
+This chaos could be solved by patching up
+every LXL, LXA or DCH in all procedures
+that could be part of the chains,
+but this is hard to implement.
+.IP 3.
+P, or any procedure called by P (transitively),
+calls a procedure whose body is not
+available as EM text.
+The unknown procedure may use an LXL, LXA or DCH.
+However, in several languages a separately
+compiled procedure has no access to the
+static or dynamic chain.
+In this case
+this point does not apply.
+.IP 4.
+P, or any procedure called by P (transitively),
+uses the LPB instruction, which converts a
+local base to an argument base;
+as the locals and parameters are stored
+in a non-standard way (differing from the
+normal EM calling sequence) this instruction
+would yield incorrect results.
+.IP 5.
+The total number of bytes of the parameters
+of P is not known.
+P may be a procedure with a variable number
+of parameters or may have an array of dynamic size
+as value parameter.
+.LP
+It is undesirable to expand a call to a procedure P in line
+in any of the following cases:
+.IP 1. 3
+P is large, i.e. the number of EM instructions
+of P exceeds some threshold.
+The expanded code would be large too.
+Furthermore, several programs in ACK,
+including the global optimizer itself,
+may run out of memory if they they have to run
+in a small address space and are provided
+very large procedures.
+The threshold may be set to infinite,
+in which case this point does not apply.
+.IP 2.
+P has many local variables.
+All these variables would have to be allocated
+in the stack frame of the calling procedure.
+.PP
+If a call may be expanded in line, we have to
+decide how to access its parameters.
+In the previous section we stated that we would
+use in line parameters whenever possible and desirable.
+There are several reasons why a parameter
+cannot or should not be expanded in line.
+.sp
+No parameter of a procedure P can be expanded in line,
+in any of the following cases:
+.IP 1. 3
+P, or any procedure called by P (transitively),
+does a store-indirect or a use-indirect (i.e. through
+a pointer).
+However, if the front-end has generated messages
+telling that certain parameters can not be accessed
+indirectly, those parameters may be expanded in line.
+.IP 2.
+P, or any procedure called by P (transitively),
+calls a procedure whose body is not available as EM text.
+The unknown procedure may do a store-indirect
+or a use-indirect.
+However, the same remark about front-end messages
+as for 1. holds here.
+.IP 3.
+The address of a parameter location is taken (via a LAL).
+In the normal calling sequence, all parameters
+are stored sequentially. If the address of one
+parameter location is taken, the address of any
+other parameter location can be computed from it.
+Hence we must put every parameter in a temporary location;
+furthermore, all these locations must be in
+the same order as for the normal calling sequence.
+.IP 4.
+P has overlapping parameters; for example, it uses
+the parameter at offset 10 both as a 2 byte and as a 4 byte
+parameter.
+Such code may be produced by the front ends if
+the formal parameter is of some record type
+with variants.
+.PP
+Sometimes a specific parameter must not be expanded in line.
+.sp 0
+An actual parameter expression cannot be expanded in line
+in any of the following cases:
+.IP 1. 3
+P stores into the parameter location.
+Even if the actual parameter expression is a simple
+variable, it is incorrect to change the 'store into
+formal' into a 'store into actual', because of
+the parameter mechanism used.
+In Pascal, the following expansion is incorrect:
+.DS
+procedure p (x:integer);
+begin
+   x := 20;
+end;
+...
+a := 10;                a := 10;
+p(a);        --->       a := 20;
+write(a);               write(a);
+.DE
+.IP 2.
+P changes any of the operands of the
+actual parameter expression.
+If the expression is expanded and evaluated
+after the operand has been changed,
+the wrong value will be used.
+.IP 3.
+The actual parameter expression has side effects.
+It must be evaluated only once,
+at the place of the call.
+.LP
+It is undesirable to expand an actual parameter in line
+in the following case:
+.IP 1. 3
+The parameter is used more than once
+(dynamically) and the actual parameter expression
+is not just a simple variable or constant.
+.LP

+ 132 - 0
doc/ego/il/il4

@@ -0,0 +1,132 @@
+.NH 2
+Heuristic rules
+.PP
+Using the information described
+in the previous section,
+we can find all calls that can
+be expanded in line, and for which
+this expansion is desirable.
+In general, we cannot expand all these calls,
+so we have to choose the 'best' ones.
+With every CAL instruction
+that may be expanded, we associate
+a \fIpay off\fR,
+which expresses how desirable it is
+to expand this specific CAL.
+.sp
+Let Tc denote the portion of EM text involved
+in a specific call, i.e. the pushing of the actual
+parameter expressions, the CAL itself,
+the popping of the parameters and the
+pushing of the result (if any, via an LFR).
+Let Te denote the EM text that would be obtained
+by expanding the call in line.
+Let Pc be the original program and Pe the program
+with Te substituted for Tc.
+The pay off of the CAL depends on two factors:
+.IP -
+T = execution_time(Pe) - execution_time(Pc)
+.IP -
+S = code_size(Pe) - code_size(Pc)
+.LP
+The change in execution time (T) depends on:
+.IP -
+T1 = execution_time(Te) - execution_time(Tc)
+.IP -
+N = number of times Te or Tc get executed.
+.LP
+We assume that T1 will be the same every
+time the code gets executed.
+This is a reasonable assumption.
+(Note that we are talking about one CAL,
+not about different calls to the same procedure).
+Hence
+.DS
+T = N * T1
+.DE
+T1 can be estimated by a careful analysis
+of the transformations that are performed.
+Below, we list everything that will be
+different when a call is expanded in line:
+.IP -
+The CAL instruction is not executed.
+This saves a subroutine jump.
+.IP -
+The instructions in the procedure prolog
+are not executed.
+These instructions, generated from the PRO pseudo,
+save some machine registers 
+(including the old LB), set the new LB and allocate space
+for the locals of the called routine.
+The savings may be less if there are no
+locals to allocate.
+.IP -
+In line parameters are not evaluated before the call
+and are not pushed on the stack.
+.IP -
+All remaining parameters are stored in local variables,
+instead of being pushed on the stack.
+.IP -
+If the number of parameters is nonzero,
+the ASP instruction after the CAL is not executed.
+.IP -
+Every reference to an in line parameter is
+substituted by the parameter expression.
+.IP -
+RET (return) instructions are replaced by
+BRA (branch) instructions.
+If the called procedure 'falls through'
+(i.e. it has only one RET, at the end of its code),
+even the BRA is not needed.
+.IP -
+The LFR (fetch function result) is not executed
+.PP
+Besides these changes, which are caused directly by IL,
+other changes may occur as IL influences other optimization
+techniques, such as Register Allocation and Constant Propagation.
+Our heuristic rules do not take into account the quite
+inpredictable effects on Register Allocation.
+It does, however, favour calls that have numeric \fIconstants\fR
+as parameter; especially the constant "0" as an inline
+parameter gets high scores,
+as further optimizations may often be possible.
+.PP
+It cannot be determined statically how often a CAL instruction gets
+executed.
+We will use \fIloop nesting\fR information here.
+The nesting level of the loop in which
+the CAL appears (if any) will be used as an
+indication for the number of times it gets executed.
+.PP
+Based on all these facts,
+the pay off of a call will be computed.
+The following model was developed empirically.
+Assume procedure P calls procedure Q.
+The call takes place in basic block B.
+.DS
+ZP = # zero parameters
+CP = # constant parameters - ZP
+LN = Loop Nesting level (0 if outside any loop)
+F  = \fIif\fR # formal parameters of Q > 0 \fIthen\fR 1 \fIelse\fR 0
+FT = \fIif\fR Q falls through \fIthen\fR 1 \fIelse\fR 0
+S  = size(Q) - 1 - # inline_parameters - F
+L  = \fIif\fR # local variables of P > 0 \fIthen\fR 0 \fIelse\fR -1
+A  = CP + 2 * ZP
+N  = \fIif\fR LN=0 and P is never called from a loop \fIthen\fR 0 \fIelse\fR (LN+1)**2
+FM = \fIif\fR B is a firm block \fIthen\fR 2 \fIelse\fR 1
+
+pay_off = (100/S + FT + F + L + A) * N * FM
+.DE
+S stands for the size increase of the program,
+which is slightly less than the size of Q.
+The size of a procedure is taken to be its number
+of (non-pseudo) EM instructions.
+The terms "loop nesting level" and "firm" were defined
+in the chapter on the Intermediate Code (section "loop tables").
+If a call is not inside a loop and the calling procedure
+is itself never called from a loop (transitively),
+then the call will probably be executed at most once.
+Such a call is never expanded in line (its pay off is zero).
+If the calling procedure doesn't have local variables, a penalty (L)
+is introduced, as it will most likely get local variables if the
+call gets expanded.

+ 440 - 0
doc/ego/il/il5

@@ -0,0 +1,440 @@
+.NH 2
+Implementation
+.PP
+A major factor in the implementation
+of Inline Substitution is the requirement
+not to use an excessive amount of memory.
+IL essentially analyzes the entire program;
+it makes decisions based on which procedure calls
+appear in the whole program.
+Yet, because of the memory restriction, it is
+not feasible to read the entire program
+in main memory.
+To solve this problem, the IL phase has been
+split up into three subphases that are executed sequentially:
+.IP 1.
+analyze every procedure; see how it accesses its parameters;
+simultaneously collect all calls
+appearing in the whole program an put them
+in a \fIcall-list\fR.
+.IP 2.
+use the call-list and decide which calls will be substituted
+in line.
+.IP 3.
+take the decisions of subphase 2 and modify the
+program accordingly.
+.LP
+Subphases 1 and 3 scan the input program; only
+subphase 3 modifies it.
+It is essential that the decisions can be made
+in subphase 2
+without using the input program,
+provided that subphase 1 puts enough information
+in the call-list.
+Subphase 2 keeps the entire call-list in main memory
+and repeatedly scans it, to
+find the next best candidate for expansion.
+.PP
+We will specify the
+data structures used by IL before 
+describing the subphases.
+.NH 3
+Data structures
+.NH 4
+The procedure table
+.PP
+In subphase 1 information is gathered about every procedure
+and added to the procedure table.
+This information is used by the heuristic rules.
+A proctable entry for procedure p has
+the following extra information:
+.IP -
+is it allowed to substitute an invocation of p in line?
+.IP -
+is it allowed to put any parameter of such a call in line?
+.IP -
+the size of p (number of EM instructions)
+.IP -
+does p 'fall through'?
+.IP -
+a description of the formal parameters that p accesses; this information
+is obtained by looking at the code of p. For every parameter f,
+we record:
+.RS
+.IP -
+the offset of f
+.IP -
+the type of f (word, double word, pointer)
+.IP -
+may the corresponding actual parameter be put in line?
+.IP -
+is f ever accessed indirectly?
+.IP -
+if f used: never, once or more than once?
+.RE
+.IP -
+the number of times p is called (see below)
+.IP -
+the file address of its call-count information (see below).
+.LP
+.NH 4
+Call-count information
+.PP
+As a result of Inline Substitution, some procedures may
+become useless, because all their invocations have been
+substituted in line.
+One of the tasks of IL is to keep track which
+procedures are no longer called.
+Note that IL is especially keen on procedures that are
+called only once
+(possibly as a result of expanding all other calls to it).
+So we want to know how many times a procedure
+is called \fIduring\fR Inline Substitution.
+It is not good enough to compute this
+information afterwards.
+The task is rather complex, because
+the number of times a procedure is called
+varies during the entire process:
+.IP 1.
+If a call to p is substituted in line,
+the number of calls to p gets decremented by 1.
+.IP 2.
+If a call to p is substituted in line,
+and p contains n calls to q, then the number of calls to q
+gets incremented by n.
+.IP 3.
+If a procedure p is removed (because it is no
+longer called) and p contains n calls to q,
+then the number of calls to q gets decremented by n.
+.LP
+(Note that p may be the same as q, if p is recursive).
+.sp 0
+So we actually want to have the following information:
+.DS
+NRCALL(p,q) = number of call to q appearing in p,
+
+for all procedures p and q that may be put in line.
+.DE
+This information, called \fIcall-count information\fR is
+computed by the first subphase.
+It is stored in a file.
+It is represented as a number of lists, rather than as
+a (very sparse) matrix.
+Every procedure has a list of (proc,count) pairs,
+telling which procedures it calls, and how many times.
+The file address of its call-count list is stored
+in its proctable entry.
+Whenever this information is needed, it is fetched from
+the file, using direct access.
+The proctable entry also contains the number of times
+a procedure is called, at any moment.
+.NH 4
+The call-list
+.PP
+The call-list is the major data structure use by IL.
+Every item of the list describes one procedure call.
+It contains the following attributes:
+.IP -
+the calling procedure (caller)
+.IP -
+the called procedure (callee)
+.IP -
+identification of the CAL instruction (sequence number)
+.IP -
+the loop nesting level; our heuristic rules appreciate
+calls inside a loop (or even inside a loop nested inside
+another loop, etc.) more than other calls
+.IP -
+the actual parameter expressions involved in the call;
+for every actual, we record:
+.RS
+.IP -
+the EM code of the expression
+.IP -
+the number of bytes of its result (size)
+.IP -
+an indication if the actual may be put in line
+.RE
+.LP
+The structure of the call-list is rather complex.
+Whenever a call is expanded in line, new calls
+will suddenly appear in the program,
+that were not contained in the original body
+of the calling subroutine.
+These calls are inherited from the called procedure.
+We will refer to these invocations as \fInested calls\fR
+(see Fig. 5.1).
+.DS
+procedure p is
+begin                           .
+     a();                       .
+     b();                       .
+end;
+
+procedure r is            procedure r is
+begin                     begin
+     x();                      x();
+     p();  -- in line          a();  -- nested call
+     y();                      b();  -- nested call
+end;                           y();
+                          end;
+
+Fig. 5.1 Example of nested procedure calls
+.DE
+Nested calls may subsequently be put in line too
+(probably resulting in a yet deeper nesting level, etc.).
+So the call-list does not always reflect the source program,
+but changes dynamically, as decisions are made.
+If a call to p is expanded, all calls appearing in p
+will be added to the call-list.
+.sp 0
+A convenient and elegant way to represent
+the call-list is to use a LISP-like list.
+.[
+poel lisp trac
+.]
+Calls that appear at the same level
+are linked in the CDR direction. If a call C
+to a procedure p is expanded,
+all calls appearing in p are put in a sub-list
+of C, i.e. in its CAR.
+In the example above, before the decision
+to expand the call to p is made, the
+call-list of procedure r looks like:
+.DS
+(call-to-x, call-to-p, call-to-y)
+.DE
+After the decision, it looks like:
+.DS
+(call-to-x, (call-to-p*, call-to-a, call-to-b), call-to-y)
+.DE
+The call to p is marked, because it has been
+substituted.
+Whenever IL wants to traverse the call-list of some procedure,
+it uses the well-known LISP technique of
+recursion in the CAR direction and
+iteration in the CDR direction
+(see page 1.19-2 of
+.[
+poel lisp trac
+.]
+).
+All list traversals look like:
+.DS
+traverse(list)
+{
+    for (c = first(list); c != 0; c = CDR(c)) {
+	if (c is marked) {
+	    traverse(CAR(c));
+	} else {
+	    do something with c
+	}
+    }
+}
+.DE
+The entire call-list consists of a number of LISP-like lists,
+one for every procedure.
+The proctable entry of a procedure contains a pointer
+to the beginning of the list.
+.NH 3
+The first subphase: procedure analysis
+.PP
+The tasks of the first subphase are to determine
+several attributes of every procedure
+and to construct the basic call-list,
+i.e. without nested calls.
+The size of a procedure is determined
+by simply counting its EM instructions.
+Pseudo instructions are skipped.
+A procedure does not 'fall through' if its CFG
+contains a basic block
+that is not the last block of the CFG and
+that ends on a RET instruction.
+The formal parameters of a procedure are determined
+by inspection of
+its code.
+.PP
+The call-list in constructed by looking at all CAL instructions
+appearing in the program.
+The call-list should only contain calls to procedures
+that may be put in line.
+This fact is only known if the procedure was
+analyzed earlier.
+If a call to a procedure p appears in the program
+before the body of p,
+the call will always be put in the call-list.
+If p is later found to be unsuitable,
+the call will be removed from the list by the
+second subphase.
+.PP
+An important issue is the recognition
+of the actual parameter expressions of the call.
+The front ends produces messages telling how many
+bytes of formal parameters every procedure accesses.
+(If there is no such message for a procedure, it
+cannot be put in line).
+The actual parameters together must account for
+the same number of bytes.A recursive descent parser is used
+to parse side-effect free EM expressions.
+It uses a table and some
+auxiliary routines to determine
+how many bytes every EM instruction pops from the stack
+and how many bytes it pushes onto the stack.
+These numbers depend on the EM instruction, its argument,
+and the wordsize and pointersize of the target machine.
+Initially, the parser has to recognize the
+number of bytes specified in the formals-message,
+say N.
+Assume the first instruction before the CAL pops S bytes
+and pushes R bytes.
+If R > N, too many bytes are recognized
+and the parser fails.
+Else, it calls itself recursively to recognize the
+S bytes used as operand of the instruction.
+If it succeeds in doing so, it continues with the next instruction,
+i.e. the first instruction before the code recognized by
+the recursive call, to recognize N-R more bytes.
+The result is a number of EM instructions that collectively push N bytes.
+If an instruction is come across that has side-effects
+(e.g. a store or a procedure call) or of which R and S cannot
+be computed statically (e.g. a LOS), it fails.
+.sp 0
+Note that the parser traverses the code backwards.
+As EM code is essentially postfix code, the parser works top down.
+.PP
+If the parser fails to recognize the parameters, the call will not
+be substituted in line.
+If the parameters can be determined, they still have to
+match the formal parameters of the called procedure.
+This check is performed by the second subphase; it cannot be
+done here, because it is possible that the called
+procedure has not been analyzed yet.
+.PP
+The entire call-list is written to a file,
+to be processed by the second subphase.
+.NH 3
+The second subphase: making decisions
+.PP
+The task of the second subphase is quite easy
+to understand.
+It reads the call-list file,
+builds an incore call-list and deletes every
+call that may not be expanded in line (either because the called
+procedure may not be put in line, or because the actual parameters
+of the call do not match the formal parameters of the called procedure).
+It assigns a \fIpay-off\fR to every call,
+indicating how desirable it is to expand it.
+.PP
+The subphase repeatedly scans the call-list and takes
+the call with the highest ratio.
+The chosen one gets marked,
+and the call-list is extended with the nested calls,
+as described above.
+These nested calls are also assigned a ratio,
+and will be considered too during the next scans.
+.sp 0
+After every decision the number of times
+every procedure is called is updated, using
+the call-count information.
+Meanwhile, the subphase keeps track of the amount of space left
+available.
+If all space is used, or if there are no more calls left to
+be expanded, it exits this loop.
+Finally, calls to procedures that are called only
+once are also chosen.
+.PP
+The actual parameters of a call are only needed by
+this subphase to assign a ratio to a call.
+To save some space, these actuals are not kept in main memory.
+They are removed after the call has been read and a ratio
+has been assigned to it.
+So this subphase works with \fIabstracts\fR of calls.
+After all work has been done,
+the actual parameters of the chosen calls are retrieved
+from a file,
+as they are needed by the transformation subphase.
+.NH 3
+The third subphase: doing transformations
+.PP
+The third subphase makes the actual modifications to
+the EM text.
+It is directed by the decisions made in the previous subphase,
+as expressed via the call-list.
+The call-list read by this subphase contains
+only calls that were selected for expansion.
+The list is ordered in the same way as the EM text,
+i.e. if a call C1 appears before a call C2 in the call-list,
+C1 also appears before C2 in the EM text.
+So the EM text is traversed linearly,
+the calls that have to be substituted are determined
+and the modifications are made.
+If a procedure is come across that is no longer needed,
+it is simply not written to the output EM file.
+The substitution of a call takes place in distinct steps:
+.IP "change the calling sequence" 7
+.sp 0
+The actual parameter expressions are changed.
+Parameters that are put in line are removed.
+All remaining ones must store their result in a
+temporary local variable, rather than
+push it on the stack.
+The CAL instruction and any ASP (to pop actual parameters)
+or LFR (to fetch the result of a function)
+are deleted.
+.IP "fetch the text of the called procedure"
+.sp 0
+Direct disk access is used to to read the text of the
+called procedure.
+The file offset is obtained from the proctable entry.
+.IP "allocate bytes for locals and temporaries"
+.sp 0
+The local variables of the called procedure will be put in the
+stack frame of the calling procedure.
+The same applies to any temporary variables
+that hold the result of parameters
+that were not put in line.
+The proctable entry of the caller is updated.
+.IP "put a label after the CAL"
+.sp 0
+If the called procedure contains a RET (return) instruction
+somewhere in the middle of its text (i.e. it does
+not fall through), the RET must be changed into
+a BRA (branch), to jump over the
+remainder of the text.
+This label is not needed if the called
+procedure falls through.
+.IP "copy the text of the called procedure and modify it"
+.sp 0
+References to local variables of the called routine
+and to parameters that are not put in line
+are changed to refer to the
+new local of the caller.
+References to in line parameters are replaced
+by the actual parameter expression.
+Returns (RETs) are either deleted or
+replaced by a BRA.
+Messages containing information about local
+variables or parameters are changed.
+Global data declarations and the PRO and END pseudos
+are removed.
+Instruction labels and references to them are
+changed to make sure they do not have the
+same identifying number as
+labels in the calling procedure.
+.IP "insert the modified text"
+.sp 0
+The pseudos of the called procedure are put after the pseudos
+of the calling procedure.
+The real text of the callee is put at
+the place where the CAL was.
+.IP "take care of nested substitutions"
+.sp 0
+The expanded procedure may contain calls that
+have to be expanded too (nested calls).
+If the descriptor of this call contains actual
+parameter expressions,
+the code of the expressions has to be changed
+the same way as the code of the callee was changed.
+Next, the entire process of finding CALs and doing
+the substitutions is repeated recursively.
+.LP

+ 27 - 0
doc/ego/il/il6

@@ -0,0 +1,27 @@
+.NH 2
+Source files of IL
+.PP
+The sources of IL are in the following files
+and packages (the prefixes 1_, 2_ and 3_ refer to the three subphases):
+.IP il.h: 14
+declarations of global variables and
+data structures
+.IP il.c:
+the routine main; the driving routines of the three subphases
+.IP 1_anal:
+contains a subroutine that analyzes a procedure
+.IP 1_cal:
+contains a subroutine that analyzes a call
+.IP 1_aux:
+implements auxiliary procedures used by subphase 1
+.IP 2_aux:
+implements auxiliary procedures used by subphase 2
+.IP 3_subst:
+the driving routine for doing the substitution
+.IP 3_change:
+lower level routines that do certain modifications
+.IP 3_aux:
+implements auxiliary procedures used by subphase 3
+.IP aux
+implements auxiliary procedures used by several subphases.
+.LP

+ 7 - 0
doc/ego/intro/head

@@ -0,0 +1,7 @@
+.ND
+.ll 80m
+.nr LL 80m
+.nr tl 78m
+.tr ~ 
+.ds >. .
+.ds [. " \[

+ 79 - 0
doc/ego/intro/intro1

@@ -0,0 +1,79 @@
+.TL
+The design and implementation of
+the EM Global Optimizer
+.AU
+H.E. Bal
+.AI
+Vrije Universiteit
+Wiskundig Seminarium, Amsterdam
+.AB
+The EM Global Optimizer is part of the Amsterdam Compiler Kit,
+a toolkit for making retargetable compilers.
+It optimizes the intermediate code common to all compilers of
+the toolkit (EM),
+so it can be used for all programming languages and
+all processors supported by the kit.
+.PP
+The optimizer is based on well-understood concepts like
+control flow analysis and data flow analysis.
+It performs the following optimizations:
+Inline Substitution, Strength Reduction, Common Subexpression Elimination,
+Stack Pollution, Cross Jumping, Branch Optimization, Copy Propagation,
+Constant Propagation, Dead Code Elimination and Register Allocation.
+.PP
+This report describes the design of the optimizer and several
+of its implementation issues.
+.AE
+.bp
+.NH 1
+Introduction
+.PP
+.FS
+This work was supported by the
+Stichting Technische Wetenschappen (STW)
+under grant VWI00.0001.
+.FE
+The EM Global Optimizer is part of a software toolkit
+for making production-quality retargetable compilers.
+This toolkit,
+called the Amsterdam Compiler Kit
+.[
+tanenbaum toolkit rapport
+.]
+.[
+tanenbaum toolkit cacm
+.]
+runs under the Unix*
+.FS
+*Unix is a Trademark of Bell Laboratories
+.FE
+operating system.
+.sp 0
+The main design philosophy of the toolkit is to use
+a language- and machine-independent
+intermediate code, called EM.
+.[
+keizer architecture
+.]
+The basic compilation process can be split up into
+two parts.
+A language-specific front end translates the source program into EM.
+A machine-specific back end transforms EM to assembly code
+of the target machine.
+.PP
+The global optimizer is an optional phase of the
+compilation process, and can be used to obtain
+machine code of a higher quality.
+The optimizer transforms EM-code to better EM-code,
+so it comes between the front end and the back end.
+It can be used with any combination of languages
+and machines, as far as they are supported by
+the compiler kit.
+.PP
+This report describes the design of the
+global optimizer and several of its
+implementation issues.
+Measurements can be found in.
+.[
+bal tanenbaum global
+.]

+ 3 - 0
doc/ego/intro/tail

@@ -0,0 +1,3 @@
+.[
+$LIST$
+.]

+ 95 - 0
doc/ego/lv/lv1

@@ -0,0 +1,95 @@
+.bp
+.NH 1
+Live-Variable analysis
+.NH 2
+Introduction
+.PP
+The "Live-Variable analysis" optimization technique (LV)
+performs some code improvements and computes information that may be
+used by subsequent optimizations.
+The main task of this phase is the 
+computation of \fIlive-variable information\fR.
+.[~[
+aho compiler design
+.] section 14.4]
+A variable A is said to be \fIdead\fR at some point p of the
+program text, if on no path in the control flow graph
+from p to a RET (return), A can be used before being changed;
+else A is said to be \fIlive\fR. 
+.PP
+A statement of the form
+.DS
+VARIABLE := EXPRESSION
+.DE
+is said to be dead if the left hand side variable is dead just after
+the statement and the right hand side expression has no
+side effects (i.e. it doesn't change any variable).
+Such a statement can be eliminated entirely.
+Dead code will seldom be present in the original program,
+but it may be the result of earlier optimizations,
+such as copy propagation.
+.PP
+Live-variable information is passed to other phases via
+messages in the EM code.
+Live/dead messages are generated at points in the EM text where
+variables become dead or live.
+This information is especially useful for the Register
+Allocation phase.
+.NH 2
+Implementation
+.PP
+The implementation uses algorithm 14.6 of.
+.[
+aho compiler design
+.]
+First two sets DEF and USE are computed for every basic block b:
+.IP DEF(b) 9
+the set of all variables that are assigned a value in b before
+being used
+.IP USE(b) 9
+the set of all variables that may be used in b before being changed.
+.LP
+(So variables that may, but need not, be used resp. changed via a procedure
+call or through a pointer are included in USE but not in DEF).
+The next step is to compute the sets IN and OUT :
+.IP IN[b] 9
+the set of all variables that are live at the beginning of b
+.IP OUT[b] 9
+the set of all variables that are live at the end of b
+.LP
+IN and OUT can be computed for all blocks simultaneously by solving the
+data flow equations:
+.DS
+(1)   IN[b] = OUT[b] - DEF[b] + USE[b]
+[2]   OUT[b] = IN[s1] + ... + IN[sn] ;
+	where SUCC[b] = {s1, ... , sn}
+.DE
+The equations are solved by a similar algorithm as for
+the Use Definition equations (see previous chapter).
+.PP
+Finally, each basic block is visited in turn to remove its dead code
+and to emit the live/dead messages.
+Every basic block b is traversed from its last
+instruction backwards to the beginning of b.
+Initially, all variables that are dead at the end
+of b are marked dead. All others are marked live.
+If we come across an assignment to a variable X that
+was marked live, a live-message is put after the
+assignment and X is marked dead;
+if X was marked dead, the assignment may be removed, provided that
+the right hand side expression contains no side effects.
+If we come across a use of a variable X that
+was marked dead, a dead-message is put after the
+use and X is marked live.
+So at any point, the mark of X tells whether X is
+live or dead immediately before that point.
+A message is also generated at the start of a basic block
+for every variable that was live at the end of the (textually)
+previous block, but dead at the entry of this block, or v.v.
+.PP
+Only local variables are considered.
+This significantly reduces the memory needed by this phase,
+eases the implementation and is hardly less efficient than
+considering all variables.
+(Note that it is very hard to prove that an assignment to
+a global variable is dead).

+ 371 - 0
doc/ego/ov/ov1

@@ -0,0 +1,371 @@
+.bp
+.NH 1
+Overview of the global optimizer
+.NH 2
+The ACK compilation process
+.PP
+The EM Global Optimizer is one of three optimizers that are
+part of the Amsterdam Compiler Kit (ACK).
+The phases of ACK are:
+.IP 1.
+A Front End translates a source program to EM
+.IP 2.
+The Peephole Optimizer
+.[
+tanenbaum staveren peephole toplass
+.]
+reads EM code and produces 'better' EM code.
+It performs a number of optimizations (mostly peephole
+optimizations)
+such as constant folding, strength reduction and unreachable code
+elimination.
+.IP 3.
+The Global Optimizer further improves the EM code.
+.IP 4.
+The Code Generator transforms EM to assembly code
+of the target computer.
+.IP 5.
+The Target Optimizer improves the assembly code.
+.IP 6.
+An Assembler/Loader generates an executable file.
+.LP
+For a more extensive overview of the ACK compilation process,
+we refer to.
+.[
+tanenbaum toolkit rapport
+.]
+.[
+tanenbaum toolkit cacm
+.]
+.PP
+The input of the Global Optimizer may consist of files and
+libraries.
+Every file or module in the library must contain EM code in
+Compact Assembly Language format.
+.[~[
+tanenbaum machine architecture
+.], section 11.2]
+The output consists of one such EM file.
+The input files and libraries together need not
+constitute an entire program,
+although as much of the program as possible should be supplied.
+The more information about the program the optimizer 
+gets, the better its output code will be.
+.PP
+The Global Optimizer is language- and machine-independent,
+i.e. it can be used for all languages and machines supported by ACK.
+Yet, it puts some unavoidable restrictions on the EM code
+produced by the Front End (see below).
+It must have some knowledge of the target machine.
+This knowledge is expressed in a machine description table
+which is passed as argument to the optimizer.
+This table does not contain very detailed information about the
+target (such as its instruction set and addressing modes).
+.NH 2
+The EM code
+.PP
+The definition of EM, the intermediate code of all ACK compilers,
+is given in a separate document.
+.[
+tanenbaum machine architecture
+.]
+We will only discuss some features of EM that are most relevant
+to the Global Optimizer.
+.PP
+EM is the assembly code of a virtual \fIstack machine\fR.
+All operations are performed on the top of the stack.
+For example, the statement "A := B + 3" may be expressed in EM as:
+.DS
+LOL -4         -- push local variable B
+LOC 3          -- push constant 3
+ADI 2          -- add two 2-byte items on top of
+	       -- the stack and push the result
+STL -2         -- pop A
+.DE
+So EM is essentially a \fIpostfix\fR code.
+.PP
+EM has a rich instruction set, containing several arithmetic
+and logical operators.
+It also contains special-case instructions (such as INCrement).
+.PP
+EM has \fIglobal\fR (\fIexternal\fR) variables, accessible
+by all procedures and \fIlocal\fR variables, accessible by a few
+(nested) procedures.
+The local variables of a lexically enclosing procedure may
+be accessed via a \fIstatic link\fR. 
+EM has instructions to follow the static chain.
+There are EM instruction to allow a procedure
+to access its local variables directly (such as LOL and STL above).
+Local variables are referenced via an offset in the stack frame
+of the procedure, rather than by their names (e.g. -2 and -4 above).
+The EM code does not contain the (source language) type
+of the variables.
+.PP
+All structured statements in the source program are expressed in
+low level jump instructions.
+Besides conditional and unconditional branch instructions, there are 
+two case instructions (CSA and CSB),
+to allow efficient translation of case statements.
+.NH 2
+Requirements on the EM input
+.PP
+As the optimizer should be useful for all languages,
+it clearly should not put severe restrictions on the EM code
+of the input.
+There is, however, one immovable requirement:
+it must be possible to determine the \fIflow of control\fR of the
+input program.
+As virtually all global optimizations are based on control flow information,
+the optimizer would be totally powerless without it.
+For this reason we restrict the usage of the case jump instructions (CSA/CSB)
+of EM.
+Such an instruction is always called with the address of a case descriptor
+on top the the stack.
+.[~[
+tanenbaum machine architecture
+.] section 7.4]
+This descriptor contains the labels of all possible
+destinations of the jump.
+We demand that all case descriptors are allocated in a global
+data fragment of type ROM, i.e. the case descriptors
+may not be modifyable.
+Furthermore, any case instruction should be immediately preceded by
+a LAE (Load Address External) instruction, that loads the
+address of the descriptor,
+so the descriptor can be uniquely identified.
+.PP
+The optimizer will work improperly if the user deceives the control flow.
+We will give two methods to do this.
+.PP
+In "C" the notorious library routines "setjmp" and "longjmp"
+.[
+unix programmer's manual
+.]
+may be used to jump out of a procedure,
+but can also be used for a number of other stuffy purposes,
+for example, to create an extra entry point in a loop.
+.DS
+ while (condition) {
+	 ....
+	 setjmp(buf);
+	 ...
+ }
+ ...
+ longjmp(buf);
+.DE
+The invocation to longjmp actually is a jump to the place of
+the last call to setjmp with the same argument (buf).
+As the calls to setjmp and longjmp are indistinguishable from
+normal procedure calls, the optimizer will not see the danger.
+No need to say that several loop optimizations will behave
+unexpectedly when presented with such pathological input.
+.PP
+Another way to deceive the flow of control is
+by using exception handling routines.
+Ada*
+.FS
+* Ada is a registered trademark of the U.S. Government
+(Ada Joint Program Office).
+.FE
+has clearly recognized the dangers of exception handling,
+but other languages (such as PL/I) have not.
+.[
+ada rationale
+.]
+.PP
+The optimizer will be more effective if the EM input contains
+some extra information about the source program.
+Especially the \fIregister message\fR is very important.
+These messages indicate which local variables may never be
+accessed indirectly.
+Most optimizations benefit significantly by this information.
+.PP
+The Inline Substitution technique needs to know how many bytes
+of formal parameters every procedure accesses.
+Only calls to procedures for which the EM code contains this information
+will be substituted in line.
+.NH 2
+Structure of the optimizer
+.PP
+The Global Optimizer is organized as a number of \fIphases\fR,
+each one performing some task.
+The main structure is as follows:
+.IP IC 6
+the Intermediate Code construction phase transforms EM into the
+intermediate code (ic) of the optimizer
+.IP CF
+the Control Flow phase extends the ic with control flow
+information and interprocedural information
+.IP OPTs
+zero or more optimization phases, each one performing one or
+more related optimizations
+.IP CA
+the Compact Assembly phase generates Compact Assembly Language EM code
+out of ic.
+.LP
+.PP
+An important issue in the design of a global optimizer is the
+interaction between optimization techniques.
+It is often advantageous to combine several techniques in
+one algorithm that takes into account all interactions between them.
+Ideally, one single algorithm should be developed that does
+all optimizations simultaneously and deals with all possible interactions.
+In practice, such an algorithm is still far out of  reach.
+Instead some rather ad hoc (albeit important) combinations are chosen,
+such as Common Subexpression Elimination and Register Allocation.
+.[
+prabhala sethi common subexpressions
+.]
+.[
+sethi ullman optimal code
+.]
+.PP
+In the Em Global Optimizer there is one separate algorithm for
+every technique.
+Note that this does not mean that all techniques are independent
+of each other.
+.PP
+In principle, the optimization phases can be run in any order;
+a phase may even be run more than once.
+However, the following rules should be obeyed:
+.IP -
+the Live Variable analysis phase (LV) must be run prior to
+Register Allocation (RA), as RA uses information outputted by LV.
+.IP -
+RA should be the last phase; this is a consequence of the way
+the interface between RA and the Code Generator is defined.
+.LP
+The ordering of the phases has significant impact on
+the quality of the produced code.
+In
+.[
+wulf overview production quality carnegie-mellon
+.]
+two kinds of phase ordering problems are distinguished.
+If two techniques A and B both take away opportunities of each other,
+there is a "negative" ordering problem.
+If, on the other hand, both A and B introduce new optimization
+opportunities for each other, the problem is called "positive".
+In the Global Optimizer the following interactions must be
+taken into account:
+.IP -
+Inline Substitution (IL) may create new opportunities for most
+other techniques, so it should be run as early as possible
+.IP -
+Use Definition analysis (UD) may introduce opportunities for LV.
+.IP -
+Strength Reduction may create opportunities for UD
+.LP
+The optimizer has a default phase ordering, which can
+be changed by the user.
+.NH 2
+Structure of this document
+.PP
+The remaining chapters of this document each describe one
+phase of the optimizer.
+For every phase, we describe its task, its design,
+its implementation, and its source files.
+The latter two sections are intended to aid the
+maintenance of the optimizer and
+can be skipped by the initial reader.
+.NH 2
+References
+.PP
+There are very 
+few modern textbooks on optimization.
+Chapters 12, 13, and 14 of
+.[
+aho compiler design
+.]
+are a good introduction to the subject.
+Wulf et. al.
+.[
+wulf optimizing compiler
+.]
+describe one specific optimizing (Bliss) compiler.
+Anklam et. al.
+.[
+anklam vax-11
+.]
+discuss code generation and optimization in
+compilers for one specific machine (a Vax-11).
+Kirchgaesner et. al. 
+.[
+optimizing ada compiler
+.]
+present a brief description of many
+optimizations; the report also contains a lengthy (over 60 pages)
+bibliography.
+.PP
+The number of articles on optimization is quite impressive.
+The Lowrey and Medlock paper on the Fortran H compiler
+.[
+object code optimization
+.]
+is a classical one.
+Other papers on global optimization are.
+.[
+faiman optimizing pascal
+.]
+.[
+perkins sites
+.]
+.[
+harrison general purpose optimizing
+.]
+.[
+morel partial redundancies
+.]
+.[
+Mintz global optimizer
+.]
+Freudenberger
+.[
+freudenberger setl optimizer
+.]
+describes an optimizer for a Very High Level Language (SETL).
+The Production-Quality Compiler-Compiler (PQCC) project uses
+very sophisticated compiler techniques, as described in.
+.[
+wulf overview ieee
+.]
+.[
+wulf overview carnegie-mellon
+.]
+.[
+wulf machine-relative
+.]
+.PP
+Several Ph.D. theses are dedicated to optimization.
+Davidson
+.[
+davidson simplifying
+.]
+outlines a machine-independent peephole optimizer that
+improves assembly code.
+Katkus
+.[
+katkus
+.]
+describes how efficient programs can be obtained at little cost by
+optimizing only a small part of a program.
+Photopoulos
+.[
+photopoulos mixed code
+.]
+discusses the idea of generating interpreted intermediate code as well
+as assembly code, to obtain programs that are both small and  fast.
+Shaffer
+.[
+shaffer automatic
+.]
+describes the theory of automatic subroutine generation.
+.]
+Leverett
+.[
+leverett register allocation compilers
+.]
+deals with register allocation in the PQCC compilers.
+.PP
+References to articles about specific optimization techniques
+will be given in later chapters.

+ 33 - 0
doc/ego/ra/ra1

@@ -0,0 +1,33 @@
+.bp
+.NH 1
+Register Allocation
+.NH 2
+Introduction
+.PP
+The efficient usage of the general purpose registers
+of the target machine plays a key role in any optimizing compiler.
+This subject, often referred to as \fIRegister Allocation\fR,
+has great impact on both the code generator and the
+optimizing part of such a compiler.
+The code generator needs registers for at least the evaluation of
+arithmetic expressions;
+the optimizer uses the registers to decrease the access costs
+of frequently used entities (such as variables).
+The design of an optimizing compiler must pay great
+attention to the cooperation of optimization, register allocation
+and code generation.
+.PP
+Register allocation has received much attention in literature (see
+.[
+leverett register allocation compilers
+.]
+.[
+chaitin register coloring
+.]
+.[
+freiburghouse usage counts
+.]
+and
+.[~[
+sites register
+.]]).

+ 139 - 0
doc/ego/ra/ra2

@@ -0,0 +1,139 @@
+.NH 2
+Usage of registers in ACK compilers
+.PP
+We will first describe the major design decisions 
+of the Amsterdam Compiler Kit,
+as far as they concern register allocation.
+Subsequently we will outline 
+the role of the Global Optimizer in the register
+allocation process and the interface
+between the code generator and the optimizer.
+.NH 3
+Usage of registers without the intervention of the Global Optimizer
+.PP
+Registers are used for two purposes:
+.IP 1.
+for the evaluation of arithmetic expressions
+.IP 2.
+to hold local variables, for the duration of the procedure they
+are local to.
+.LP
+It is essential to note that no translation part of the compilers,
+except for the code generator, knows anything at all
+about the register set of the target computer.
+Hence all decisions about registers are ultimately made by
+the code generator.
+Earlier phases of a compiler can only \fIadvise\fR the code generator.
+.PP
+The code generator splits the register set into two:
+a fixed part for the evaluation of expressions (called \fIscratch\fR
+registers) and a fixed part to store local variables.
+This partitioning, which depends only on the target computer, significantly
+reduces the complexity of register allocation, at the penalty
+of some loss of code quality.
+.PP
+The code generator has some (machine-dependent) knowledge of the access costs
+of memory locations and registers and of the costs of saving and
+restoring registers. (Registers are always saved by the \fIcalled\fR
+procedure).
+This knowledge is expressed in a set of procedures for each target machine.
+The code generator also knows how many registers there are and of
+which type they are.
+A register can be of type \fIpointer\fR, \fIfloating point\fR
+or \fIgeneral\fR.
+.PP
+The front ends of the compilers determine which local variables may
+be put in a register;
+such a variable may never be accessed indirectly (i.e. through a pointer).
+The front end also determines the types and sizes of these variables.
+The type can be any of the register types or the type \fIloop variable\fR,
+which denotes a general-typed variable that is used as loop variable
+in a for-statement.
+All this information is collected in a \fIregister message\fR in
+the EM code.
+Such a message is a pseudo EM instruction.
+This message also contains a \fIscore\fR field,
+indicating how desirable it is to put this variable in a register.
+A front end may assign a high score to a variable if it
+was declared as a register variable (which is only possible in
+some languages, such as "C").
+Any compiler phase before the code generator may change this score field,
+if it has reason to do so.
+The code generator bases its decisions on the information contained
+in the register message, most notably on the score.
+.PP
+If the global optimizer is not used,
+the score fields are set by the Peephole Optimizer.
+This optimizer simply counts the number of occurrences
+of every local (register) variable and adds this count
+to the score provided by the front end.
+In this way a simple, yet quite effective
+register allocation scheme is achieved.
+.NH 3
+The role of the Global Optimizer
+.PP
+The Global Optimizer essentially tries to improve the scheme
+outlined above.
+It uses the following principles for this purpose:
+.IP -
+Entities are not always assigned a register for the duration
+of an entire procedure; smaller regions of the program text
+may be considered too.
+.IP -
+several variables may be put in the same register simultaneously,
+provided at most one of them is live at any point.
+.IP -
+besides local variables, other entities (such as constants and addresses of
+variables and procedures) may be put in a register.
+.IP -
+more accurate cost estimates are used.
+.LP
+To perform its task, the optimizer must have some
+knowledge of the target machine.
+.NH 3
+The interface between the register allocator and the code generator
+.PP
+The RA phase of the optimizer must somehow be able to express its
+decisions.
+Such decisions may look like: 'put constant 1283 in a register from
+line 12 to line 40'.
+To be precise, RA must be able to tell the code generator to:
+.IP -
+initialize a register with some value
+.IP -
+update an entity from a register
+.IP -
+replace all occurrences of an entity in a certain region
+of text by a reference to the register.
+.LP
+At least three problems occur here: the code generator is only used to
+put local variables in registers,
+it only assigns a register to a variable for the duration of an entire
+procedure and it is not used to have some earlier compiler phase
+make all the decisions.
+.PP
+All problems are solved by one mechanism, that involves no changes
+to the code generator.
+With every (non-scratch) register R that will be used in
+a procedure P, we associate a new variable T, local to P.
+The size of T is the same as the size of R.
+A register message is generated for T with an exceptionally high score.
+The scores of all original register messages are set to zero.
+Consequently, the code generator will always assign precisely those new
+variables to a register.
+If the optimizer wants to put some entity, say the constant 1283, in
+a register, it emits the code "T := 1283" and replaces all occurrences
+of '1283' by T.
+Similarly, it can put the address of a procedure in T and replace all
+calls to that procedure by indirect calls.
+Furthermore, it can put several different entities in T (and thus in R)
+during the lifetime of P.
+.PP
+In principle, the code generated by the optimizer in this way would
+always be valid EM code, even if the optimizer would be presented
+a totally wrong description of the target computer register set.
+In practice, it would be a waste of data as well as text space to
+allocate memory for these new variables, as they will always be assigned
+a register (in the correct order of events).
+Hence, no memory locations are allocated for them.
+For this reason they are called pseudo local variables.

+ 383 - 0
doc/ego/ra/ra3

@@ -0,0 +1,383 @@
+.NH 2
+The register allocation phase
+.PP
+.NH 3
+Overview
+.PP
+The RA phase deals with one procedure at a time.
+For every procedure, it first determines which entities
+may be put in a register. Such an entity
+is called an \fIitem\fR.
+For every item it decides during which parts of the procedure it
+might be assigned a register.
+Such a region is called a \fItimespan\fR.
+For any item, several (possibly overlapping) timespans may
+be considered.
+A pair (item,timespan) is called an \fIallocation\fR.
+If the items of two allocations are both live at some
+point of time in the intersections of their timespans,
+these allocations are said to be \fIrivals\fR of each other,
+as they cannot be assigned the same register.
+The rivals-set of every allocation is computed.
+Next, the gains of assigning a register to an allocation are estimated,
+for every allocation.
+With all this information, decisions are made which allocations
+to store in which registers (\fIpacking\fR).
+Finally, the EM text is transformed to reflect these decisions.
+.NH 3
+The item recognition subphase
+.PP
+RA tries to put the following entities in a register:
+.IP -
+a local variable for which a register message was found
+.IP -
+the address of a local variable for which no
+register message was found
+.IP -
+the address of a global variable
+.IP -
+the address of a procedure
+.IP -
+a numeric constant.
+.LP
+Only the \fIaddress\fR of a global variable
+may be put in a register, not the variable itself.
+This approach avoids the very complex problems that would be
+caused by procedure calls and indirect pointer references (see
+.[~[
+aho design compiler
+.] sections 14.7 and 14.8]
+and 
+.[~[
+spillman side-effects
+.]]).
+Still, on most machines accessing a global variable using indirect
+addressing through a register is much cheaper than
+accessing it via its address.
+Similarly, if the address of a procedure is put in a register, the
+procedure can be called via an indirect call.
+.PP
+With every item we associate a register type.
+This type is
+.DS
+for local variables: the type contained in the register message
+for addresses of variables and procedures: the pointer type
+for constants: the general type
+.DE
+An entity other than a local variable is not taken to be an item
+if it is used only once within the current procedure.
+.PP
+An item is said to be \fIlive\fR at some point of the program text
+if its value may be used before it is changed.
+As addresses and constants are never changed, all items but local
+variables are always live.
+The region of text during which a local variable is live is
+determined via the live/dead messages generated by the
+Live Variable analysis phase of the Global Optimizer.
+.NH 3
+The allocation determination subphase
+.PP
+If a procedure has more items than registers,
+it may be advantageous to put an item in a register
+only during those parts of the procedure where it is most
+heavily used.
+Such a part will be called a timespan.
+With every item we may associate a set of timespans.
+If two timespans of an item overlap,
+at most one of them may be granted a register,
+as there is no use in putting the same item in two
+registers simultaneously.
+If two timespans of an item are distinct,
+both may be chosen;
+the item will possibly be put in two
+different registers during different parts of the procedure.
+The timespan may also consist
+of the whole procedure.
+.PP
+A list of (item,timespan) pairs (allocations)
+is build, which will be the input to the decision making
+subphase of RA (packing subphase).
+This allocation list is the main data structure of RA.
+The description of the remainder of RA will be in terms
+of allocations rather than items.
+The phrase "to assign a register to an allocation" means "to assign
+a register to the item of the allocation for the duration of
+the timespan of the allocation".
+Subsequent subphases will add more information
+to this list.
+.PP
+Several factors must be taken into account when a
+timespan for an item is constructed:
+.IP 1.
+At any \fIentry point\fR of the timespan where the
+item is live,
+the register must be initialized with the item
+.IP 2.
+At any exit point of the timespan where the item is live,
+the item must be updated.
+.LP
+In order to decrease these costs, we will only consider timespans with
+one entry point
+and no live exit points.
+.NH 3
+The rivals computation subphase
+.PP
+As stated before, several different items may be put in the
+same register, provided they are not live simultaneously.
+For every allocation we determine the intersection
+of its timespan and the lifetime of its item (i.e. the part of the
+procedure during which the item is live).
+The allocation is said to be busy during this intersection.
+If two allocations are ever busy simultaneously they are
+said to be rivals of each other.
+The rivals information is added to the allocation list.
+.NH 3
+The profits computation subphase
+.PP
+To make good decisions, the packing subphase needs to
+know which allocations can be assigned the same register
+(rivals information) and how much is gained by
+granting an allocation a register.
+.PP
+Besides the gains of using a register instead of an
+item,
+two kinds of overhead costs must be
+taken into account:
+.IP -
+the register must be initialized with the item
+.IP -
+the register must be saved at procedure entry
+and restored at procedure exit.
+.LP
+The latter costs should not be due to a single
+allocation, as several allocations can be assigned the same register.
+These costs are dealt with after packing has been done.
+They do not influence the decisions of the packing algorithm,
+they may only undo them.
+.PP
+The actual profits consist of improvements
+of execution time and code size.
+As the former is far more difficult to estimate , we will 
+discuss code size improvements first.
+.PP
+The gains of putting a certain item in a register
+depends on how the item is used.
+Suppose the item is
+a pointer variable.
+On machines that do not have a
+double-indirect addressing mode,
+two instructions are needed to dereference the variable
+if it is not in a register, but only one if it is put in a register.
+If the variable is not dereferenced, but simply copied, one instruction
+may be sufficient in both cases.
+So  the gains of putting a pointer variable in a register are higher
+if the variable is dereferenced often.
+.PP
+To make accurate estimates, detailed knowledge of
+the target machine and of the code generator
+would be needed.
+Therefore, a simplification has been made that substantially limits
+the amount of target machine information that is needed.
+The estimation of the number of bytes saved does
+not take into account how an item is used.
+Rather, an average number is used.
+So these gains are computed as follows:
+.DS
+#bytes_saved = #occurrences * gains_per_occurrence
+.DE
+The number of occurrences is derived from
+the EM code.
+Note that this is not exact either,
+as there is no one-to-one correspondence between occurrences in
+the EM code and in the assembler code.
+.PP
+The gains of one occurrence depend on:
+.IP 1.
+the type of the item
+.IP 2.
+the size of the item
+.IP 3.
+the type of the register
+.LP
+and for local variables and addresses of local variables:
+.IP 4.
+the type of the local variable
+.IP 5.
+the offset of the variable in the stackframe
+.LP
+For every allocation we try two types of registers: the register type
+of the item and the general register type.
+Only the type with the highest profits will subsequently be used.
+This type is added to the allocation information.
+.PP
+To compute the gains, RA uses a machine-dependent table
+that is read from a machine descriptor file.
+By means of this table the number of bytes saved can be computed
+as a function of the five properties.
+.PP
+The costs of initializing a register with an item
+is determined in a similar way.
+The cost of one initialization is also
+obtained from the descriptor file.
+Note that there can be at most one initialization for any
+allocation.
+.PP
+To summarize, the number of bytes a certain allocation would
+save is computed as follows:
+.DS
+net_bytes_saved =  bytes_saved - init_cost
+bytes_saved =      #occurrences * gains_per_occ
+init_cost =        #initializations * costs_per_init
+.DE
+.PP
+It is inherently more difficult to estimate the execution
+time saved by putting an item in a register,
+because it is impossible to predict how
+many times an item will be used dynamically.
+If an occurrence is part of a loop,
+it may be executed many times.
+If it is part of a conditional statement, 
+it may never be executed at all.
+In the latter case, the speed of the program may even get
+worse if an initialization is needed.
+As a clear example, consider the piece of "C" code in Fig. 13.1.
+.DS
+switch(expr) {
+      case 1:  p(); break;
+      case 2:  p(); p(); break;
+      case 3:  p(); break;
+      default: break;
+}
+
+Fig. 13.1 A "C" switch statement
+.DE
+Lots of bytes may be saved by putting the address of procedure p
+in a register, as p is called four times (statically).
+Dynamically, p will be called zero, one or two times,
+depending on the value of the expression.
+.PP
+The optimizer uses the following strategy for optimizing
+execution time:
+.IP 1.
+try to put items in registers during \fIloops\fR first
+.IP 2.
+always keep the initializing code outside the loop
+.IP 3.
+if an item is not used in a loop, do not put it in a register if
+the initialization costs may be higher than the gains
+.LP
+The latter condition can be checked by determining the 
+minimal number of usages (dynamically) of the item during the procedure,
+via a shortest path algorithm.
+In the example above, this minimal number is zero, so the address of
+p is not put in a register.
+.PP
+The costs of one occurrence is estimated as described above for the
+code size.
+The number of dynamic occurrences is guessed by looking at the
+loop nesting level of every occurrence.
+If the item is never used in a loop,
+the minimal number of occurrences is used.
+From these facts, the execution time improvement is assessed
+for every allocation.
+.NH 3
+The packing subphase
+.PP
+The packing subphase takes as input the allocation
+list and outputs a
+description of which allocations should be put
+in which registers.
+So it is essentially the decision making part of RA.
+.PP
+The packing system tries to assign a register to allocations one
+at a time, in some yet to be defined order.
+For every allocation A, it first checks if there is a register
+(of the right type)
+that is already assigned to one or more allocations,
+none of which are rivals of A.
+In this case A is assigned the same register.
+Else, A is assigned a new register, if one exists.
+A table containing the number of free registers for every type
+is maintained.
+It is initialized with the number of non-scratch registers of
+the target computer and updated whenever a
+new register is handed out.
+The packing algorithm stops when no more allocations can 
+or need be assigned a register.
+.PP
+After an allocation A has been packed,
+all allocations with non-disjunct timespans (including
+A itself) are removed from the allocation list.
+.PP
+In case the number of items exceeds the number of registers, it
+is important to choose the most profitable allocations.
+Due to the possibility of having several allocations
+occupying the same register,
+this problem is quite complex.
+Our packing algorithm uses simple heuristic rules
+and avoids any combinatorial search.
+It has distinct rules for different costs measures.
+.PP
+If object code size is the most important factor,
+the algorithm is greedy and chooses allocations in
+decreasing order of their profits attribute.
+It does not take into account the fact that
+other allocations may be passed over because of
+this decision.
+.PP
+If execution time is at prime stake, the algorithm
+first considers allocations whose timespans consist of loops.
+After all these have been packed, it considers the remaining
+allocations.
+Within the two subclasses, it considers allocations
+with the highest profits first.
+When assigning a register to an allocation with a loop
+as timespan, the algorithm checks if the item has
+already been put in a register during another loop.
+If so, it tries to use the same register for the
+new allocation.
+After all packing has been done,
+it checks if the item has always been assigned the same
+register (although not necessarily during all loops).
+If so, it tries to put the item in that register during
+the entire procedure. This is possible
+if the allocation (item,whole_procedure) is not a rival
+of any allocation with a different item that has been
+assigned to the same register.
+Note that this approach is essentially 'bottom up',
+as registers are first assigned over small regions
+of text which are later collapsed into larger regions.
+The advantage of this approach is the fact that
+the decisions for one loop can be made independently
+of all other loops.
+.PP
+After the entire packing process has been completed,
+we compute for each register how much is gained in using
+this register, by simply adding the net profits
+of all allocations assigned to it.
+This total yield should outweigh the costs of
+saving/restoring the register at procedure entry/exit.
+As most modern processors (e.g. 68000, Vax) have special
+instructions to save/restore several registers,
+the differential costs of saving one extra register are by
+no means constant.
+The costs are read from the machine descriptor file and
+compared to the total yields of the registers.
+As a consequence of this analysis, some allocations 
+may have their registers taken away.
+.NH 3
+The transformation subphase
+.PP
+The final subphase of RA transforms the EM text according to the
+decisions made by the packing system.
+It traverses the text of the currently optimized procedure and
+changes all occurrences of items at points where
+they are assigned a register.
+It also clears the score field of the register messages for
+normal local variables and emits register messages with a very
+high score for the pseudo locals.
+At points where registers have to be initialized with items,
+it generates EM code to do so.
+Finally it tries to decrease the size of the stackframe
+of the procedure by looking at which local variables need not
+be given memory locations.

+ 28 - 0
doc/ego/ra/ra4

@@ -0,0 +1,28 @@
+.NH 2
+Source files of RA
+.PP
+The sources of RA are in the following files and packages:
+.IP ra.h: 14
+declarations of global variables and data structures
+.IP ra.c:
+the routine main; initialization of target machine-dependent tables
+.IP items:
+a routine to build the list of items of one procedure;
+routines to manipulate items
+.IP lifetime:
+contains a subroutine that determines when items are live/dead
+.IP alloclist:
+contains subroutines that build the initial allocations list
+and that compute the rivals sets.
+.IP profits:
+contains a subroutine that computes the profits of the allocations
+and a routine that determines the costs of saving/restoring registers
+.IP pack:
+contains the packing subphase
+.IP xform:
+contains the transformation subphase
+.IP interval:
+contains routines to manipulate intervals of time
+.IP aux:
+contains auxiliary routines
+.LP

+ 171 - 0
doc/ego/sp/sp1

@@ -0,0 +1,171 @@
+.bp
+.NH 1
+Stack pollution
+.NH 2
+Introduction
+.PP
+The "Stack Pollution" optimization technique (SP) decreases the costs
+(time as well as space) of procedure calls.
+In the EM calling sequence, the actual parameters are popped from
+the stack by the \fIcalling\fR procedure.
+The ASP (Adjust Stack Pointer) instruction is used for this purpose.
+A call in EM is shown in Fig. 8.1
+.DS
+Pascal:                EM:
+
+f(a,2)                 LOC 2
+		       LOE A
+		       CAL F
+		       ASP 4    -- pop 4 bytes
+
+Fig. 8.1 An example procedure call in Pascal and EM
+.DE
+As procedure calls occur often in most programs,
+the ASP is one of the most frequently used EM instructions.
+.PP
+The main intention of removing the actual parameters after a procedure call
+is to avoid the stack size to increase rapidly.
+Yet, in some cases, it is possible to \fIdelay\fR or even \fIavoid\fR the
+removal of the parameters without letting the stack grow
+significantly.
+In this way, considerable savings in code size and execution time may
+be achieved, at the cost of a slightly increased stack size.
+.PP
+A stack adjustment may be delayed if there is some other stack adjustment
+later on in the same basic block.
+The two ASPs can be combined into one.
+.DS
+Pascal:           EM:               optimized EM:
+
+f(a,2)            LOC 2             LOC 2
+g(3,b,c)          LOE A             LOE A
+		  CAL F             CAL F
+		  ASP 4             LOE C
+		  LOE C             LOE B
+		  LOE B             LOC 3
+		  LOC 3             CAL G
+		  CAL G             ASP 10
+		  ASP 6
+
+Fig. 8.2 An example of local Stack Pollution
+.DE
+The stacksize will be increased only temporarily.
+If the basic block contains another ASP, the ASP 10 may subsequently be
+combined with that next ASP, and so on.
+.PP
+For some back ends, a stack adjustment also takes place
+at the point of a procedure return.
+There is no need to specify the number of bytes to be popped at a
+return.
+This provides an opportunity to remove ASPs more globally.
+If all ASPs outside any loop are removed, the increase of the
+stack size will still only be small, as no such ASP is executed more
+than once without an intervening return from the procedure it is part of.
+.PP
+This second approach is not generally applicable to all target machines,
+as some back ends require the stack to be cleaned up at the point of
+a procedure return.
+.NH 2
+Implementation
+.PP
+There is one main problem the implementation has to solve.
+In EM, the stack is not only used for passing parameters,
+but also for evaluating expressions.
+Hence, ASP instructions can only be combined or removed
+if certain conditions are satisfied.
+.PP
+Two consecutive ASPs of one basic block can only be combined
+(as described above) if:
+.IP 1.
+On no point of text in between the two ASPs, any item is popped from
+the stack that was pushed onto it before the first ASP.
+.IP 2.
+The number of bytes popped from the stack by the second ASP must equal
+the number of bytes pushed since the first ASP.
+.LP
+Condition 1. is not satisfied in Fig. 8.3.
+.DS
+Pascal:               EM:
+
+5 + f(10) + g(30)     LOC 5
+		      LOC 10
+		      CAL F
+		      ASP 2    -- cannot be removed
+		      LFR 2    -- push function result
+		      ADI 2
+		      LOC 30
+		      CAL G
+		      ASP 2
+		      LFR 2
+		      ADI 2
+Fig. 8.3 An illegal transformation
+.DE
+If the first ASP were removed (delayed), the first ADI would add
+10 and f(10), instead of 5 and f(10).
+.sp
+Condition 2. is not satisfied in Fig. 8.4.
+.DS
+Pascal:               EM:
+
+f(10) + 5 * g(30)     LOC 10
+		      CAL F
+		      ASP 2
+		      LFR 2
+		      LOC 5
+		      LOC 30
+		      CAL G
+		      ASP 2
+		      LFR 2
+		      MLI 2   --  5 * g(30)
+		      ADI 2
+
+Fig. 8.4 A second illegal transformation
+.DE
+If the two ASPs were combined into one 'ASP 4', the constant 5 would
+have been popped, rather than the parameter 10 (so '10 + f(10)*g(30)'
+would have been computed).
+.PP
+The second approach to deleting ASPs (i.e. let the procedure return
+do the stack clean-up)
+is only applied to the last ASP of every basic block.
+Any preceding ASPs are dealt with by the first approach.
+The last ASP of a basic block B will only be removed if:
+.IP -
+on no path in the control flow graph from B to any block containing a
+RET (return) there is a basic block that, at some point of its text, pops
+items from the stack that it has not itself pushed earlier.
+.LP
+Clearly, if this condition is satisfied, no harm can be done; no
+other basic block will ever access items that were pushed
+on the stack before the ASP.
+.PP
+The number of bytes pushed onto or popped from the stack can be
+easily encoded in a so called "pop-push table".
+The numbers in general depend on the target machine word- and pointer
+size and on the argument given to the instruction.
+For example, an ADS instruction is described by:
+.DS
+   -a-p+p
+.DE
+which means: an 'ADS n' first pops an n-byte value (n being the argument),
+next pops a pointer-size value and finally pushes a pointer-size value.
+For some infrequently used EM instructions the pop-push numbers
+cannot be computed statically.
+.PP
+The stack pollution algorithm first performs a depth first search over
+the control flow graph and marks all blocks that do not satisfy
+the global condition.
+Next it visits all basic blocks in turn.
+For every pair of adjacent ASPs, it checks conditions 1. and 2. and
+combines the ASPs if they are satisfied.
+The new ASP may be used as first ASP in the next pair.
+If a condition fails, it simply continues with the next ASP.
+Finally, the last ASP is removed if:
+.IP -
+nothing has been popped from the stack after the last ASP that was
+pushed before it
+.IP -
+the block was not marked by the depth first search
+.IP -
+the block is not in a loop
+.LP

+ 44 - 0
doc/ego/sr/sr1

@@ -0,0 +1,44 @@
+.bp
+.NH 1
+Strength reduction
+.NH 2
+Introduction
+.PP
+The Strength Reduction optimization technique (SR)
+tries to replace expensive operators
+by cheaper ones,
+in order to decrease the execution time
+of the program.
+A classical example is replacing a 'multiplication by 2'
+by an addition or a shift instruction.
+These kinds of local transformations are already
+done by the EM Peephole Optimizer.
+Strength reduction can also be applied
+more generally to operators used in a loop.
+.DS
+i := 1;                    i := 1;
+while i < 100 loop  -->    TMP := i * 118;
+   put(i * 118);           while i < 100 loop
+   i := i + 1;                put(TMP);
+end loop;                     i := i + 1;
+			      TMP := TMP + 118;
+			   end loop;
+
+Fig. 6.1 An example of Strenght Reduction
+.DE
+In Fig. 6.1, a multiplication inside a loop is
+replaced by an addition inside the loop and a multiplication
+outside the loop.
+Clearly, this is a global optimization; it cannot
+be done by a peephole optimizer.
+.PP
+In some cases a related technique, \fItest replacement\fR,
+can be used to eliminate the
+loop variable i.
+This technique will not be discussed in this report.
+.sp 0
+In the example above, the resulting code
+can be further optimized by using
+constant propagation.
+Obviously, this is not the task of the
+Strength Reduction phase.

+ 217 - 0
doc/ego/sr/sr2

@@ -0,0 +1,217 @@
+.NH 2
+The model of strength reduction
+.PP
+In this section we will describe 
+the transformations performed by
+Strength Reduction (SR).
+Before doing so, we will introduce the
+central notion of an induction variable.
+.NH 3
+Induction variables
+.PP
+SR looks for variables whose
+values form an arithmetic progression
+at the beginning of a loop.
+These variables are called induction variables.
+The most frequently occurring example of such
+a variable is a loop-variable in a high-order
+programming language.
+Several quite sophisticated models of strength
+reduction can be found in the literature.
+.[
+cocke reduction strength cacm
+.]
+.[
+allen cocke kennedy reduction strength
+.]
+.[
+lowry medlock cacm
+.]
+.[
+aho compiler design
+.]
+In these models the notion of an induction variable
+is far more general than the intuitive notion
+of a loop-variable.
+The definition of an induction variable we present here
+is more restricted,
+yielding a simpler model and simpler transformations.
+We think the principle source for strength reduction lies in
+expressions using a loop-variable,
+i.e. a variable that is incremented or decremented
+by the same amount after every loop iteration,
+and that cannot be changed in any other way.
+.PP
+Of course, the EM code does not contain high level constructs
+such as for-statements.
+We will define an induction variable in terms
+of the Intermediate Code of the optimizer.
+Note that the notions of a loop in the
+EM text and of a firm basic block
+were defined in section 3.3.5.
+.sp
+.UL definition
+.sp 0
+An induction variable i of a loop L is a local variable
+that is never accessed indirectly,
+whose size is the word size of the target machine, and
+that is assigned exactly once within L,
+the assignment:
+.IP -
+being of the form i := i + c or i := c +i,
+c is a constant
+called the \fIstep value\fR of i.
+.IP -
+occurring in a firm block of L.
+.LP
+(Note that the first restriction on the assignment
+is not described in terms of the Intermediate Code;
+we will give such a description later; the current
+definition is easier to understand however).
+.NH 3
+Recognized expressions
+.PP
+SR recognizes certain expressions using
+an induction variable and replaces
+them by cheaper ones.
+Two kinds of expensive operations are recognized:
+multiplication and array address computations.
+The expressions that are simplified must
+use an induction variable
+as an operand of
+a multiplication or as index in an array expression.
+.PP
+Often a linear function of an induction variable is used,
+rather than the variable itself.
+In these cases optimization is still possible.
+We call such expressions \fIiv-expressions\fR.
+.sp
+.UL definition:
+.sp 0
+An iv-expression of an induction variable i of a loop L is
+an expression that:
+.IP -
+uses only the operators + and - (unary as well as binary)
+.IP -
+uses i as operand exactly once
+.IP -
+uses (besides i) only constants or variables that are
+never changed in L as operands.
+.LP
+.PP
+The expressions recognized by SR are of the following forms:
+.IP (1)
+iv_expression * constant
+.IP (2)
+constant * iv_expression
+.IP (3)
+A[iv-expression] :=       (assign to array element)
+.IP (4)
+A[iv-expression]          (use array element)
+.IP (5)
+& A[iv-expression]        (take address of array element)
+.LP
+(Note that EM has different instructions to use an array element,
+store into one, or take the address of one, resp. LAR, SAR, and AAR).
+.sp 0
+The size of the elements of A must
+be known statically.
+In cases (3) and (4) this size 
+must equal the word size of the
+target machine.
+.NH 3
+Transformations
+.PP
+With every recognized expression we associate
+a new temporary local variable TMP,
+allocated in the stack frame of the
+procedure containing the expression.
+At any program point within the loop, TMP will
+contain the following value:
+.IP multiplication: 18
+the current value of iv-expression * constant
+.IP arrays:
+the current value of &A[iv-expression].
+.LP
+In the second case, TMP essentially is a pointer variable,
+pointing to the element of A that is currently in use.
+.sp 0
+If the same expression occurs several times in the loop,
+the same temporary local is used each time.
+.PP
+Three transformations are applied to the EM text:
+.IP (1)
+TMP is initialized with the right value.
+This initialization takes place just
+before the loop.
+.IP (2)
+The recognized expression is simplified.
+.IP (3)
+TMP is incremented; this takes place just
+after the induction variable is incremented.
+.LP
+For multiplication, the initial value of TMP
+is the value of the recognized expression at
+the program point immediately before the loop.
+For arrays, TMP is initialized with the address
+of the first array element that is accessed.
+So the initialization code is:
+.DS
+TMP := iv-expression * constant;  or
+TMP := &A[iv-expression]
+.DE
+At the point immediately before the loop,
+the induction variable will already have been
+initialized,
+so the value used in the code above will be the
+value it has during the first iteration.
+.PP
+For multiplication, the recognized expression can simply be
+replaced by TMP.
+For array optimizations, the replacement
+depends on the form:
+.DS
+\fIform\fR                         \fIreplacement\fR
+(3) A[iv-expr] :=            *TMP :=     (assign indirect)
+(4) A[iv-expr]               *TMP        (use indirect)
+(5) &A[iv-expr]              TMP
+.DE
+The '*' denotes the indirect operator. (Note that
+EM has different instructions to do
+an assign-indirect and a use-indirect).
+As the size of the array elements is restricted
+to be the word size in case (3) and (4),
+only one EM instruction needs to
+be generated in all cases.
+.PP
+The amount by which TMP is incremented is:
+.IP multiplication: 18
+step value * constant
+.IP arrays:
+step value * element size
+.LP
+Note that the step value (see definition of induction variable above),
+the constant, and the element size (see previous section) can all
+be determined statically.
+If the sign of the induction variable in the
+iv-expression is negative, the amount
+must be negated.
+.PP
+The transformations are demonstrated by an example.
+.DS
+i := 100;                     i := 100;
+while i > 1 loop              TMP := (6-i) * 5;
+   X := (6-i) * 5 + 2;        while i > 1 loop
+   Y := (6-i) * 5 - 8;   -->     X := TMP + 2;
+   i := i - 3;                   Y := TMP - 8;
+end loop;                        i := i - 3;
+			         TMP := TMP + 15;
+			      end loop;
+
+Fig. 6.2 Example of complex Strength Reduction transformations
+.DE
+The expression '(6-i)*5' is recognized twice. The constant
+is 5.
+The step value is -3.
+The sign of i in the recognized expression is '-'.
+So the increment value of TMP is -(-3*5) = +15.

+ 232 - 0
doc/ego/sr/sr3

@@ -0,0 +1,232 @@
+.NH 2
+Implementation
+.PP
+Like most phases, SR deals with one procedure
+at a time.
+Within a procedure, SR works on one loop at a time.
+Loops are processed in textual order.
+If loops are nested inside each other,
+SR starts with the outermost loop and proceeds in the
+inwards direction.
+This order is chosen,
+because it enables the optimization
+of multi-dimensional array address computations,
+if the elements are accessed in the usual way
+(i.e. row after row, rather than column after column).
+For every loop, SR first detects all induction variables
+and then tries to recognize
+expressions that can be optimized.
+.NH 3
+Finding induction variables
+.PP
+The process of finding induction variables
+can conveniently be split up
+into two parts.
+First, the EM text of the loop is scanned to find
+all \fIcandidate\fR induction variables,
+which are word-sized local variables
+that are assigned precisely once
+in the loop, within a firm block.
+Second, for every candidate, the single assignment
+is inspected, to see if it has the form
+required by the definition of an induction variable.
+.PP
+Candidates are found by scanning the EM code of the loop.
+During this scan, two sets are maintained.
+The set "cand" contains all variables that were
+assigned exactly once so far, within a firm block.
+The set "dismiss" contains all variables that
+should not be made a candidate.
+Initially, both sets are empty.
+If a variable is assigned to, it is put
+in the cand set, if three conditions are met:
+.IP 1.
+the variable was not in cand or dismiss already
+.IP 2.
+the assignment takes place in a firm block
+.IP 3.
+the assignment is not a ZRL instruction (assignment by zero)
+or a SDL instruction (store double local).
+.LP
+If any condition fails, the variable is dismissed from cand
+(if it was there already) and put in dismiss
+(if it was not there already).
+.sp 0
+All variables for which no register message was generated (i.e. those
+variables that may be accessed indirectly) are assumed
+to be changed in the loop.
+.sp 0
+All variables that remain in cand are candidate induction variables.
+.PP
+From the set of candidates, the induction variables can
+be determined, by inspecting the single assignment.
+The assignment must match one of the EM patterns below.
+('x' is the candidate. 'ws' is the word size of the target machine.
+'n' is any number.)
+.DS
+\fIpattern\fR                                     \fIstep size\fR
+INL x  |                                      +1
+DEL x  |                                      -1
+LOL x ; (INC | DEC) ; STL x  |                +1 | -1
+LOL x ; LOC n ; (ADI ws | SBI ws) ; STL x  |  +n | -n
+LOC n ; LOL x ; ADI ws ; STL x.               +n
+.DE
+From the patterns the step size of the induction variable
+can also be determined.
+These step sizes are displayed on the right hand side.
+.sp
+For every induction variable we maintain the following information:
+.IP -
+the offset of the variable in the stackframe of its procedure
+.IP -
+a pointer to the EM text of the assignment statement
+.IP -
+the step value
+.LP
+.NH 3
+Optimizing expressions
+.PP
+If any induction variables of the loop were found,
+the EM text of the loop is scanned again,
+to detect expressions that can be optimized.
+SR scans for multiplication and array instructions.
+Whenever it finds such an instruction, it analyses the
+code in front of it.
+If an expression is to be optimized, it must
+be generated by the following syntax rules.
+.DS
+   optimizable_expr:
+		iv_expr const mult |
+		const iv_expr mult |
+		address iv_expr address array_instr;
+   mult:
+		MLI ws |
+		MLU ws ;
+   array_instr:
+		LAR ws |
+		SAR ws |
+		AAR ws ;
+   const:
+		LOC n ;
+.DE
+An 'address' is an EM instruction that loads an
+address on the stack.
+An instruction like LOL may be an 'address', if
+the size of an address (pointer size, =ps) is
+the same as the word size.
+If the pointer size is twice the word size,
+instructions like LDL are an 'address'.
+(The addresses in the third grammar rule
+denote resp. the array address and the
+array descriptor address).
+.DS
+   address:
+		LAE |
+		LAL |
+		LOL if ps=ws |
+		LOE    ,,    |
+		LIL    ,,    |
+		LDL if ps=2*ws |
+		LDE    ,,      ;
+.DE
+The notion of an iv-expression was introduced earlier.
+.DS
+   iv_expr:
+		iv_expr unair_op |
+		iv_expr iv_expr binary_op |
+		loopconst |
+		iv ;
+   unair_op:
+		NGI ws |
+		INC |
+		DEC ;
+   binary_op:
+		ADI ws |
+		ADU ws |
+		SBI ws |
+		SBU ws ;
+   loopconst:
+		const |
+		LOL x  if x is not changed in loop ;
+   iv:
+		LOL x  if x is an induction variable ;
+.DE
+An iv_expression must satisfy one additional constraint:
+it must use exactly one operand that is an induction
+variable.
+A simple, hand written, top-down parser is used
+to recognize an iv-expression.
+It scans the EM code from right to left
+(recall that EM is essentially postfix).
+It uses semantic attributes (inherited as well as
+derived) to check the additional constraint.
+.PP
+All information assembled during the recognition
+process is put in a 'code_info' structure.
+This structure contains the following information:
+.IP -
+the optimizable code itself
+.IP -
+the loop and basic block the code is part of
+.IP -
+the induction variable
+.IP -
+the iv-expression
+.IP -
+the sign of the induction variable in the
+iv-expression
+.IP -
+the offset and size of the temporary local variable
+.IP -	
+the expensive operator (MLI, LAR etc.)
+.IP -
+the instruction that loads the constant
+(for multiplication) or the array descriptor
+(for arrays).
+.LP
+The entire transformation process is driven
+by this information.
+As the EM text is represented internally
+as a list, this process consists
+mainly of straightforward list manipulations.
+.sp 0
+The initialization code must be put
+immediately before the loop entry.
+For this purpose a \fIheader block\fR is
+created that has the loop entry block as
+its only successor and that dominates the
+entry block.
+The CFG and all relations (SUCC,PRED, IDOM, LOOPS etc.)
+are updated.
+.sp 0
+An EM instruction that will
+replace the optimizable code
+is created and put at the place of the old code.
+The list representing the old optimizable code
+is used to create a list for the initializing code,
+as they are similar.
+Only two modifications are required:
+.IP -
+if the expensive operator is a LAR or SAR,
+it must be replaced by an AAR, as the initial value
+of TMP is the \fIaddress\fR of the first
+array element that is accessed.
+.IP -
+code must be appended to store the result of the
+expression in TMP.
+.LP
+Finally, code to increment TMP is created and put after
+the code of the single assignment to the
+induction variable.
+The generated code uses either an integer addition
+(ADI) or an integer-to-pointer addition (ADS)
+to do the increment.
+.PP
+SR maintains a set of all expressions that have already
+been recognized in the present loop.
+Such expressions are said to be \fIavailable\fR.
+If an expression is recognized that is
+already available,
+no new temporary local variable is allocated for it,
+and the code to initialize and increment the local
+is not generated.

+ 28 - 0
doc/ego/sr/sr4

@@ -0,0 +1,28 @@
+.NH 2
+Source files of SR
+.PP
+The sources of SR are in the following files
+and packages:
+.IP sr.h: 14
+declarations of global variables and
+data structures
+.IP sr.c:
+the routine main; a driving routine to process
+(possibly nested) loops in the right order
+.IP iv
+implements a procedure that finds the induction variables
+of a loop
+.IP reduce
+implements a procedure that finds optimizable expressions
+and that does the transformations
+.IP cand
+implements a procedure that finds the candidate induction
+variables; used to implement iv
+.IP xform
+implements several useful routines that transform
+lists of EM text or a CFG; used to implement reduce
+.IP expr
+implements a procedure that parses iv-expressions
+.IP aux
+implements several auxiliary procedures.
+.LP

+ 58 - 0
doc/ego/ud/ud1

@@ -0,0 +1,58 @@
+.bp
+.NH 1
+Use-Definition analysis
+.NH 2
+Introduction
+.PP
+The "Use-Definition analysis" phase (UD) consists of two related optimization
+techniques that both depend on "Use-Definition" information.
+The techniques are Copy Propagation and Constant Propagation.
+They are best explained via an example (see Figs. 11.1 and 11.2).
+.DS
+   (1)  A := B                  A := B
+	 ...          -->        ...
+   (2)  use(A)                  use(B)
+
+Fig. 11.1 An example of Copy Propagation
+.DE
+.DS
+   (1)  A := 12                  A := 12
+	 ...          -->        ...
+   (2)  use(A)                  use(12)
+
+Fig. 11.2 An example of Constant Propagation
+.DE
+Both optimizations have to check that the value of A at line (2)
+can only be obtained at line (1).
+Copy Propagation also has to assure that the value of B is
+the same at line (1) as at line (2).
+.PP
+One purpose of both transformations is to introduce
+opportunities for the Dead Code Elimination optimization.
+If the variable A is used nowhere else, the assignment A := B
+becomes useless and can be eliminated.
+.sp 0
+If B is less expensive to access than A (e.g. this is sometimes the case
+if A is a local variable and B is a global variable),
+Copy Propagation directly improves the code itself.
+If A is cheaper to access the transformation will not be performed.
+Likewise, a constant as operand may be cheeper than a variable.
+Having a constant as operand may also facilitate other optimizations.
+.PP
+The design of UD is based on the theory described in section
+14.1 and 14.3 of.
+.[
+aho compiler design
+.]
+As a main departure from that theory,
+we do not demand the statement A := B to become redundant after
+Copy Propagation.
+If B is cheaper to access than A, the optimization is always performed;
+if B is more expensive than A, we never do the transformation.
+If A and B are equally expensive UD uses the heuristic rule to
+replace infrequently used variables by frequently used ones.
+This rule increases the chances of the assignment to become useless.
+.PP
+In the next section we will give a brief outline of the data
+flow theory used
+for the implementation of UD.

+ 64 - 0
doc/ego/ud/ud2

@@ -0,0 +1,64 @@
+.NH 2
+Data flow information
+.PP
+.NH 3
+Use-Definition information
+.PP
+A \fIdefinition\fR of a variable A is an assignment to A.
+A definition is said to \fIreach\fR a point p if there is a
+path in the control flow graph from the definition to p, such that
+A is not redefined on that path.
+.PP
+For every basic block B, we define the following sets:
+.IP GEN[b] 9
+the set of definitions in b that reach the end of b.
+.IP KILL[b]
+the set of definitions outside b that define a variable that
+is changed in b.
+.IP IN[b]
+the set of all definitions reaching the beginning of b.
+.IP OUT[b]
+the set of all definitions reaching the end of b.
+.LP
+GEN and KILL can be determined by inspecting the code of the procedure.
+IN and OUT are computed by solving the following data flow equations:
+.DS
+(1)    OUT[b] = IN[b] - KILL[b] + GEN[b]
+(2)    IN[b]  = OUT[p1] + ... + OUT[pn],
+	 where PRED(b) = {p1, ... , pn}
+.DE
+.NH 3
+Copy information
+.PP
+A \fIcopy\fR is a definition of the form "A := B".
+A copy is said to be \fIgenerated\fR in a basic block n if
+it occurs in n and there is no subsequent assignment to B in n.
+A copy is said to be \fIkilled\fR in n if:
+.IP (i)
+it occurs in n and there is a subsequent assignment to B within n, or
+.IP (ii)
+it occurs outside n, the definition A := B reaches the beginning of n
+and B is changed in n (note that a copy also is a definition).
+.LP
+A copy \fIreaches\fR a point p, if there are no assignments to B
+on any path in the control flow graph from the copy to p.
+.PP
+We define the following sets:
+.IP C_GEN[b] 11
+the set of all copies in b generated in b.
+.IP C_KILL[b]
+the set of all copies killed in b.
+.IP C_IN[b]
+the set of all copies reaching the beginning of b.
+.IP C_OUT[b]
+the set of all copies reaching the end of b.
+.LP
+C_IN and C_OUT are computed by solving the following equations:
+(root is the entry node of the current procedure; '*' denotes
+set intersection)
+.DS
+(1)    C_OUT[b] = C_IN[b] - C_KILL[b] + C_GEN[b]
+(2)    C_IN[b]  = C_OUT[p1] * ... * C_OUT[pn],
+	 where PRED(b) = {p1, ... , pn} and b /= root
+       C_IN[root] = {all copies}
+.DE

+ 26 - 0
doc/ego/ud/ud3

@@ -0,0 +1,26 @@
+.NH 2
+Pointers and subroutine calls
+.PP
+The theory outlined above assumes that variables can
+only be changed by a direct assignment.
+This condition does not hold for EM.
+In case of an assignment through a pointer variable,
+it is in general impossible to see which variable is affected
+by the assignment.
+Similar problems occur in the presence of procedure calls.
+Therefore we distinguish two kinds of definitions:
+.IP -
+an \fIexplicit\fR definition is a direct assignment to one
+specific variable
+.IP -
+an \fIimplicit\fR definition is the potential alteration of
+a variable as a result of a procedure call or an indirect assignment.
+.LP
+An indirect assignment causes implicit definitions to
+all variables that may be accessed indirectly, i.e. 
+all local variables for which no register message was generated
+and all global variables.
+If a procedure contains an indirect assignment it may change the
+same set of variables, else it may change some global variables directly.
+The KILL, GEN, IN and OUT sets contain explicit as well
+as implicit definitions.

+ 78 - 0
doc/ego/ud/ud4

@@ -0,0 +1,78 @@
+.NH 2
+Implementation
+.PP
+UD first builds a number of tables:
+.IP locals: 9
+contains information about the local variables of the
+current procedure (offset,size,whether a register message was found
+for it and, if so, the score field of that message)
+.IP defs:
+a table of all explicit definitions appearing in the
+current procedure.
+.IP copies:
+a table of all copies appearing in the
+current procedure.
+.LP
+Every variable (local as well as global), definition and copy
+is identified by a unique number, which is the index
+in the table.
+All tables are constructed by traversing the EM code.
+A fourth table, "vardefs" is used, indexed by a 'variable number',
+which contains for every variable the set of explicit definitions of it.
+Also, for each basic block b, the set CHGVARS containing all variables
+changed by it is computed.
+.PP
+The GEN sets are obtained in one scan over the EM text,
+by analyzing every EM instruction.
+The KILL set of a basic block b is computed by looking at the
+set of variables
+changed by b (i.e. CHGVARS[b]).
+For every such variable v, all explicit definitions to v
+(i.e. vardefs[v]) that are not in GEN[b] are added to KILL[b].
+Also, the implicit defininition of v is added to KILL[b].
+Next, the data flow equations for use-definition information
+are solved,
+using a straight forward, iterative algorithm.
+All sets are represented as bitvectors, so the operations
+on sets (union, difference) can be implemented efficiently.
+.PP
+The C_GEN and C_KILL sets are computed simultaneously in one scan
+over the EM text.
+For every copy A := B appearing in basic block b we do
+the following:
+.IP 1.
+for every basic block n /= b that changes B, see if the definition A := B
+reaches the beginning of n (i.e. check if the index number of A := B in
+the "defs" table is an element of IN[n]);
+if so, add the copy to C_KILL[n]
+.IP 2.
+if B is redefined later on in b, add the copy to C_KILL[b], else
+add it to C_GEN[b]
+.LP
+C_IN and C_OUT are computed from C_GEN and C_KILL via the second set of
+data flow equations.
+.PP
+Finally, in one last scan all opportunities for optimization are
+detected.
+For every use u of a variable A, we check if
+there is a unique explicit definition d reaching u.
+.sp
+If the definition is a copy A := B and B has the same value at d as
+at u, then the use of A at u may be changed into B.
+The latter condition can be verified as follows:
+.IP -
+if u and d are in the same basic block, see if there is
+any assignment to B in between d and u
+.IP -
+if u and d are in different basic blocks, the condition is
+satisfied if there is no assignment to B in the block of u prior to u
+and d is in C_IN[b].
+.LP
+Before the transformation is actually done, UD first makes sure the
+alteration is really desirable, as described before.
+The information needed for this purpose (access costs of local and
+global variables) is read from a machine descriptor file.
+.sp
+If the only definition reaching u has the form "A := constant", the use
+of A at u is replaced by the constant.
+

+ 19 - 0
doc/ego/ud/ud5

@@ -0,0 +1,19 @@
+
+.NH 2
+Source files of UD
+.PP
+The sources of UD are in the following files and packages:
+.IP ud.h: 14
+declarations of global variables and data structures
+.IP ud.c:
+the routine main; initialization of target machine dependent tables
+.IP defs:
+routines to compute the GEN and KILL sets and routines to analyse
+EM instructions
+.IP const:
+routines involved in constant propagation
+.IP copy:
+routines involved in copy propagation
+.IP aux:
+contains auxiliary routines
+.LP