The impact of interprocedural analysis and optimization on the design of a software development environment

One of the primary goals of the IR n programming environment project is to mount a concerted attack on the problems of performing interprocedural analysis and optimization in a compiler. Few commercial optimizing compilers employ interprocedural techniques because the cost of gathering the requisite information in a traditional compiler is too great. Computing the side effects of a procedure call requires detailed knowledge of the internals of both the called procedure and any procedures invoked either directly or indirectly from it. Thus, the compiler potentially needs information about the internals of every procedure to determine the side effects of procedure calls, even separately compiled procedures. Gathering this information would require examining the source of every procedure in the program - an expensive process, particularly unfortunate since the primary goal of separate compilation is to reduce the amount of recompilation required in response to changes in an individual procedure. The existence of a software development environment like the IR n programming environment [HoKe 84] changes the compilation process enough to make computing such information palatable. Since all modules are developed and all programs are defined using tools of the environment, these tools can cooperate to record the information necessary to do a good job of interprocedural analysis and optimization. Whenever the compiler needs information about possible side effects of a particular procedure, it can simply extract this information from the environment's central database. Because the only mechanism for changing modules or programs is through the tools provided by the environment, the compiler is assured that it will be notified of any changes. Thus, it can use information derived from previous analysis with certain knowledge that the information reflects the current state of the program and its procedures.