CA2102089C - Recompilation of computer programs for enhanced optimization - Google Patents
Recompilation of computer programs for enhanced optimizationInfo
- Publication number
- CA2102089C CA2102089C CA002102089A CA2102089A CA2102089C CA 2102089 C CA2102089 C CA 2102089C CA 002102089 A CA002102089 A CA 002102089A CA 2102089 A CA2102089 A CA 2102089A CA 2102089 C CA2102089 C CA 2102089C
- Authority
- CA
- Canada
- Prior art keywords
- procedures
- target
- program
- procedure
- computer program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/443—Optimisation
Abstract
An optimising compiler for producing executable programs from code, high level languages compiles the code whilst generating data from which a callgraph may be constructed, and then recompiles the procedures identified in the callgraph in an order which reverses the topology of the callgraph while monitoring usage of hardware registers. Procedures which are rarely or never called, or result in termination of the program, are identified, and are modified if needed so that if called, registers which they may modify are saved prior to execution of the procedure and subsequently restored if necessary, so that in a calling procedure, subsequently recompiled, no account need be taken of possible register usage by the called procedure. This makes additional registers available to the calling procedure, and enables register storing and restoring which must otherwise be associated with the callsite to be eliminated.
Description
~A9-93-016 1 - 2 ~ 0 2 0 8 9 RECOMPILATION OF COMPUTER PROGRAMS
FOR ENEIANCED OPTIMIZATION
Background of the Invention This invention relates to the compiling of source code of computer programs written in high level 5 languages in order to generate object code suitable for execution on a target computer, and more particularly to the optimization of such code using a recompilation technique to provide maximum efficiency in both execution and compilation.
High level l~ng~l~ge statements are tr~n.ql~ted during compilation into procedures capable of implementing the statement, but since these procedures must be capable of functioning in any 10 environment in which this l~n3~ e st~tennent may occur, the code produced tends to include a high degree of redllnd~ncy and compromise unless subject to optimization. The term procedure as used in this specification should be regarded as including routines and functions which will result in a procedure call from a call site when compiled.
O~ ~i~lion is a generic term utilized for modifications applied to source code, object code, or any 15 intermediate code featuring in a compilation, in order to increase the efficiency of the compiling process. Efficiency in this context may refer to improving the speed of execution of the final object code, reducing object code size or improving compilation speed to improve productivity during program development, bearing in mind that repeated recompilations will gradually be necessary during such development.
FOR ENEIANCED OPTIMIZATION
Background of the Invention This invention relates to the compiling of source code of computer programs written in high level 5 languages in order to generate object code suitable for execution on a target computer, and more particularly to the optimization of such code using a recompilation technique to provide maximum efficiency in both execution and compilation.
High level l~ng~l~ge statements are tr~n.ql~ted during compilation into procedures capable of implementing the statement, but since these procedures must be capable of functioning in any 10 environment in which this l~n3~ e st~tennent may occur, the code produced tends to include a high degree of redllnd~ncy and compromise unless subject to optimization. The term procedure as used in this specification should be regarded as including routines and functions which will result in a procedure call from a call site when compiled.
O~ ~i~lion is a generic term utilized for modifications applied to source code, object code, or any 15 intermediate code featuring in a compilation, in order to increase the efficiency of the compiling process. Efficiency in this context may refer to improving the speed of execution of the final object code, reducing object code size or improving compilation speed to improve productivity during program development, bearing in mind that repeated recompilations will gradually be necessary during such development.
2 0 Optimization may take place at various stages during the compilation process, but techniques fall broadly into two categories - front end, during which the source or intermediate code is modified so as to ~limin~te redundancies and unused code, and so as to favour the generation of more efficient object code, and back end, in which object code ., ., ~
21~2~89 generated is modifiecl, usually in the latter case to improve execution speed.
Central processing units utilized in general purpose programmable computers make extensive use of hardware registers to hold data items utilized during program execution, thus avoiding the overhead associated with memory references, and effective management of such registers forms a major aspect of compiler optimization, although the number, size and restrictions of use of such registers may vary widely from processor to processor. Some general principles relating to such management are discussed in an article "Effective Register Management During Code Generation", K.M. Gilbert, IBM~ Technical Disclosure Bulletin, January 1973, pages 2640 to 2645. Optimization -techniques in compilers for reduced instruction set (RISC) computers are discussed in an article "Advanced Compiler Technology for the RISC System/6000~
Architecture", by O'Brien e~ al, at pages 154-161 of IBM RISC
System/6000 Technology, published l9g0 by IBM Corporation.
Both of these documents emphasize the importance of efficient hardware register usage.
Only a limited number of registers is usually available for general purpose usage in typical processors, and a compiler must typically make pessimistic assumptions as to the possibility of these registers being modified by any procedure referenced during compilation. According to the nature of the compiler and/or processor, certain registers may be generically identified as modifiable by procedures or "volatile". In IBM's RISC System 6000 target processor, many of the registers are volatile: of condition registers 0 to 7, 2 through 4 are volatile; of general purpose registers 0 to 31, and 0 and 3 through 12 are volatile; and of floating point registers 0 to 31, 0 throuc311 13 are volatile. Individual procedures may be characteri~ed by all or some lesser number of registers being subject to modification, although in the context in which a procedure is called the actual number of regis-ters subject to modifica-tion may be smaller. This last information has to date been of little use in a loop involving multiple procedures. Entry to a procedure normally entails saving the content of all registers subject to modification by that procedure or any other procedures called by it, which imposes considerable overhead both in terms of the machine cycles required to implement the save (and subsequent restore) operations, and in stack 5 usage.
Summary of the Invention It is an object of the present invention to provide a back-end optimization technique both for reducing this undesirable overhead, and improving the efficiency, in terms of compilation time with which other techniques may be applied by reducing the amount of code to be processed by such techniques.
10 The invention provides a method of compiling a computer program written in a high level l~n~l~ge to provide a program executable upon a target computer comprising precompiling the program, collecting callgraph data concerning the procedures it contains and the sites from which these procedures are called, identifying target procedures which are rarely or never called during normal execution or which do not return from a call, and recompiling the program to provide said executable 15 program, in reverse topological order to that indicated by the callgraph data, including any necessary code in target procedures such that register usage by such procedures can be and is ignored during recompilation a non-target procedure calling a target procedure.
The invention extends to a method of compiling a computer program from code modules of a high or intermediate level l~ngu~ge, to provide object code executable on a target computer having 20 hardware registers available for the storage of data used by the program during execution, comprising:
compiling the code modules, processing data, produced during at least one of compiling of the code modules and execution of an executable program produced by linking of the modules, to produce a call graph of procedures comprised by the program, and to identify target procedures ln the category of at least one of procedures rarely or never called during normal execution of the program and procedures which never return from a call;
recompiling the procedures, recompilation of identified target procedures being with the inclusion of code at the entry of the procedure to save all hardware registers modifiable thereby, and with the inclusion of code to restore the saved registers if the procedure returns, whereby said target procedures may be considered in compiling of procedures containing their callsites to use no hardware registers.
The invention also extends to apparatus for compiling computer programs to convert modular source code into object code executable upon a target computer, by a method according to the invention, which apparatus may contain a general purpose computer configured to carry out the method by the loading of a compiler program implementing the invention. The invention further extends to media recorded with a compiler program for so configuring a general purpose computer.
Unlike conventional optimization techniques, which are typically intraprocedural, ;mplementation of the present invention is dependent ~pOtl the relationships between procedures; thus a rarely or once used procedure is modified in a manner which reduces its performance in order to improve the performance of another procedure, more frequently used calling the modified procedure. To the extent that these interprocedural relation.sllip.s must be analyzed in order to apply the invention, it is ~iseful and convenient to apply the invention in conjunction wilh other optimization techniques which can utilize such an arlalysis, and the nature of the analysis may take this illtO account, as in the following example: however such other optimization techniques do not form part of the present inventiotl.
The invention is further clescribed with reference to the e 2 1 0 2 0 8 9 -.,A9-93-016 5 following description of an exemplary compiler incorporating the invention.
Brief Description of the Drawings Figure l is a block diagram of the structure of relevant portions of a compiler implementing the invention;
Figure 2 is graphical representation of the call graph of a simple program;
Figure 3 is graphical illustration of the operation of the present information applied to a callgraph;
and Figure 4 is a flow diagram illustrating the computer-implemented steps for practising the method of the invention; and Figure 5 on the same page as Figure 3, is a block diagram of apparatus used to implement the invention.
Detailed Description of the Preferred Embodiments In order to implement the present invention, a program must be compiled twice, first to provide information upon interprocedural relationships, and secondly to apply the information gathered.
The system incorporated in the compiler of Figure l is thus a two-pass system. The first pass, which is performed at compile time, collects summary information for each procedure compiled. The second pass, which is performed at link time, merges the collected information and uses it to compute an interprocedural solution for the entire application. The application is then rebuilt using the interprocedural solution to enhance optimization. In the example shown, a command option to 2 0 a compiler 2, upon its invocation to compile source code modules, causes it to collect interprocedural information about procedures which it compiles. A command option to a compiler loop module 4 (or a Linker could be used) upon its invocation to link object code produced by the compiler causes 2I ~2 0 .
the loop module to use the interprocedural information to recompile the modules with enhanced optimization, and link the interprocedurally optimized versions of object code to form a "golden" output file lO.
Information collection during compilation is triggered by the use of the designated command option. Summary information for the file and each procedure is collected during compilation and is written to the object file produced for use at link 6.
Each object file 6 is associated with an appropriately identified section containing the additional information.
This information could of course be collected in a separate file if more convenient.
This summary information includes:
The fully qualified source file name.
The name of each contained procedure (with sufficient information to avoid ambiguity).
The compiler options invoked.
A list of all callsites in each procedure, again with sufficient information to avoid any ambiguity in identification.
Constant propagation information for parameters at each callsite.
Alias information for each procedure.
Information as to suitability for other optimization techniques, i.e. inlining and cloning, such as intermediate language size, automatic storage usage, and constant parameters, for each procedure.
Callsite post-dominance information.
A measure of code motion out of loops as computed by the Morel-Reinvest and the common subexpressions algorithms.
2la,~3 Register pressure/coloring (usage) information.
When all files in the application have been compiled, the user invokes the compiler loop module 4 through the compiler, again with the command option mentioned above. The link time driver 8 reads the summary information from the object files 6 and, optionally, from a profiling sample 12 produced by running a profiler on an outE~tlt file produced by a previous linking of the object file 6, and computes the application's callgraph utilizing known callgraphing techniques.
For example, consider the application shown below:
File a.c: Eile b.c:
main() bar() .
foo(); foobar();
bar()'; }
} File c.:
foobar() foo() foo(); }
Figure 2 shows the callgraph for this example. Information that will allow the driver 8 to construct the application's callgraph is contained in each of the three object files. For enhanced optimization in the invention, the driver causes a bottom-up (reverse topological ordered) recompilation 14 of the application. In our example the ordering is a.c(foo), c.c(foobar), b.c(bar) and a.c(main). The optimizer is repetitively invoked, by the driver program, in this order once the interprocedural solution for the entire application has been computed.
~1~2~83 The interprocedural .solution is computed in several steps:
Alias information for each procedure is propagated upwards in the callgraph to the root.
Constant parameter information is propagated downwards in the callgraph to the leaves.
Profile information, if available, is read and callgraph edges are marked with traversal counts (see Fig. 3).
Heuristic algorithms are run to identify candidates for various optimization techniques, including that of the invention.
As each procedure in the application is recompiled, register usage information is saved and fed back into subsequent recompilations. It is useful for compilers designed for a particular hardware platform to respect conventions as to which available hardware registers may be modified by procedures as compiled. Eor example, in the RISC System/6000 target processor, linkage convention dictates that general purpose registers 9,1, and 3-1~, floating-point registers 0-13, condition registers 9, ~, 5, 6, and 7, and the count register are volatile. In the absence of information to the contrary, the caller must assume that the values contained in volatile registers are killed by the callee.
The compiler recompiles the application at link time in reverse topological callgraph order. Hence callee procedures will be recompiled before their callers. By storing information 26 about actual register usage in the callee in memory 28, the unaltered volatile registers are still available for use by the cal]er. This process may be referred to as register resurrection Register resurrection permits an application to make better ~1se of the available hardware ~1 ~2~Y
register file. The application should experience less storage traffic caused by reduced register save/restore code and reduced register spill code, that is traffic to and from the stack due to insufficient hardware registers being available to service a procedure.
Even when analysis determines that a reference to a procedure may invalidate register's contents, there may be a benefit to moving the register save-and-restore code that would otherwise be required in the calling procedure. This technique is beneficial where the procedure is known to be referenced only very rarely, such as debuggjng and error handling procedures.
-~~ For example:
-Preserve.f DO I=l,OOOOO
C ... Code that manipulates may scalars or arrays IF (Xl(I).GT.l.OE32) CALL ERRORl(Xl(I)) IF (xl(I).LT.O.lE-32) CALL ERROR2(Xl(I)) C ... Code that does some more with these scalars or arrays ENDDO
Without modification of the called procedures, the compiler ~ assumes that linkage-converltiorl volatile registers are invalidated by the referen(es to ERRORl and ERROR2, and so additional code may be generated to restore any values that were in registers before the references and that are required after the references. This additional code can reduce performance and increase the code size of the loop, which can - increase instruction cache miss delays. However, if ERRORl and ERROR2 are almost never called, the code to save and restore invalidated registers can be transferred into the procedures so that there is no need to reload the values within the referencing procedure. This is done by placing register saving code at the start of each procedure, and placing register restoring code at the end of the procedure.
21~2ass ~ - CA9-93-016 10 Eventhough this may result in a larger object file, instruction cache and proces.sor usage are improved because the - register-preserving code is almost never loaded into the instruction cache and is almost never executed.
Moving register save-and-restore code is useful for error-handling or range-checking procedures where the error or out-of-range value is found on]y rarely.
If a referenced procedure always terminates a program, there is no reason to invalida-te registers when the procedure is referenced. In the following C example, the standard function exit() is called within a conditional block. Normally, the compiler inserts code before and possibly after the call to exit() to save and restore any required registers that may be invalidated by the call.
int main(void) ~ ~ ~ /
for (i=O;i<lOOOO;i++) if (a[i]~10000.0) bailout(-1);
else a[il+=b[i]*cli]
}
* *
~ ~ ~
}
int bailout(int retcode) ~
printf("Error: ~5\n",msg[-retcode]);
exit(retcode);
}
The compiler does not know -Ihat exit() is a function that never returns, and that preserving the registers across the reference to bailout() is therefore pointless. This is also true for the C functions abort() and terminate()(or assert()) in the RISC System 6000 taryet environment, the Fortran STOP
statement, and other terminAtirlg procedures. The lin]~er can 2la2~3 be instructed to treat certain standard procedures as terminating procedures, by specifying an exits suboption.
This suboption does not allow terminating procedures.
However, the callgraph can establish that a procedure always calls a terminating procedure, and can propagate this information upwards in the calling chain so that registers are not preserved around references to terminating procedures, upon call of which the preservation of registering becomes immaterial.
However, the most beneficial application of the invention is in conjunction with profiling data feedback. Functions that are never called in a profiling sample 12 will be modified as described above, as may other functions that are called with less than a predetermined frequency. The profiling i information may be collected from a single run, or the usermay collect information from several typical runs. In any event, the sample obtained is considered to be representative of the running application and procedures for modification are selected accordingly. As seen in Figure 3, the inclusion of - profiling information in the callgraph enables procedures at boundaries between frequently called procedures 16 and rarely or never called procedures 18, 20, 22 to be modified as described above. It should be noted that application of the invention is only needed at the points where a frequently ; executed procedure calls an infrequently called procedure, since inherently the infrequently called procedure can only itself make infrequent calls.
Other optimization tec~miques benefit from the above use of profiling information, such as inlining and cloning. There is no benefit in inlining or cloning never called or infrequently called procedures. This a]lows more aggressive inlining or cloning of more highly used routines since concerns about code-size explosions caused by over-inlining will not become a factor as quickly. Figure 3 shows a generic callgraph whose edges are labelled, via profiling feedback, with the frequency they are traversed. With this information, modification of 2~02a89 the routines 18 and 20 isolates the entire subtree below the "firewalls" 24 erected hy sucll modification, which ensures that register usage by the producers 18, 20 and 22 is invisible to the procedures 16; this same information indicates that there is no benefit in applying inlining or cloning techniques to the call beyond the firewalls.
Once it has been determined necessary to construct a "firewall" in a code module, the generation steps set out in the schematic flow diagram of Figure 4 are followed.
Register allocation 40 is accomplished by passing the program code through a register al]ocation algorithm to compute the solutions for each disjoint class of registers on the target computer. A suitable register allocation algorithm is described, for example in an article: "Register Allocation and Spilling Via Graph Coloring:, by Chaitin et al, in Computer Language, 6:47-57, 1981.
The register allocal:ion 40 yields the register allocation output 42 for each register class.
Multiple passes of the regi.~ter allocation loop 40, 42 may be necessary to compute and allocate the solutions for all the register classes for the target machine. For example, in the RISC System/6000 target enviromnent, there are three classes of registers, so that three passes of the register allocation algorithm are required.
Followlng the register a]location for all classes of registers, code is generated in the prologue of the program 44 to reserve a portion of -the al1tomatic stack storage to hold all of tl~e modified volati]e registers. This stack storage is of course allocated at rl1ntime.
Then, for each modified register, code is generated in each module 46 as follows: code is ge1lerated in the prologue to implement a store of the proper widtil into the next available ~102~89 slot in the reserved storage, and is generated in the epilogue to implement a load of the proper width from the same slot in the reserved storage back into the same volatile register.
Each generated module in a computer program then includes:
Prologue Code Main code for module r~. . Epilogue Code Referring to Figure 5, the compiling method of the invention may be implemented utilizing a general purpose computer 30, which may be similar or dissimilar to the target computer of the compilation depending on whether a regular or cross-compiler is being implemented. The computer has a conventional console 32 providing a user interface, and conventional storage for both data 34 and programs 36. A
program 38 stored on suitable media is loaded into the computer's program storage to configure it as compiling apparatus. The data storage 34 may receive data input from a profiler 40 which may be imp]emented either utilizing the same computer or separately.
-- It should be understood that the compiler may accept as input --~ either a conventional high level language, or an intermediate language to which the high ~evel language has already been translated; the latter may be advantageous in that it permits many of the programs making up a compiler suite to be common to several different languages, which are translated to a common intermediate language by appropriate front end modules.
21~2~89 generated is modifiecl, usually in the latter case to improve execution speed.
Central processing units utilized in general purpose programmable computers make extensive use of hardware registers to hold data items utilized during program execution, thus avoiding the overhead associated with memory references, and effective management of such registers forms a major aspect of compiler optimization, although the number, size and restrictions of use of such registers may vary widely from processor to processor. Some general principles relating to such management are discussed in an article "Effective Register Management During Code Generation", K.M. Gilbert, IBM~ Technical Disclosure Bulletin, January 1973, pages 2640 to 2645. Optimization -techniques in compilers for reduced instruction set (RISC) computers are discussed in an article "Advanced Compiler Technology for the RISC System/6000~
Architecture", by O'Brien e~ al, at pages 154-161 of IBM RISC
System/6000 Technology, published l9g0 by IBM Corporation.
Both of these documents emphasize the importance of efficient hardware register usage.
Only a limited number of registers is usually available for general purpose usage in typical processors, and a compiler must typically make pessimistic assumptions as to the possibility of these registers being modified by any procedure referenced during compilation. According to the nature of the compiler and/or processor, certain registers may be generically identified as modifiable by procedures or "volatile". In IBM's RISC System 6000 target processor, many of the registers are volatile: of condition registers 0 to 7, 2 through 4 are volatile; of general purpose registers 0 to 31, and 0 and 3 through 12 are volatile; and of floating point registers 0 to 31, 0 throuc311 13 are volatile. Individual procedures may be characteri~ed by all or some lesser number of registers being subject to modification, although in the context in which a procedure is called the actual number of regis-ters subject to modifica-tion may be smaller. This last information has to date been of little use in a loop involving multiple procedures. Entry to a procedure normally entails saving the content of all registers subject to modification by that procedure or any other procedures called by it, which imposes considerable overhead both in terms of the machine cycles required to implement the save (and subsequent restore) operations, and in stack 5 usage.
Summary of the Invention It is an object of the present invention to provide a back-end optimization technique both for reducing this undesirable overhead, and improving the efficiency, in terms of compilation time with which other techniques may be applied by reducing the amount of code to be processed by such techniques.
10 The invention provides a method of compiling a computer program written in a high level l~n~l~ge to provide a program executable upon a target computer comprising precompiling the program, collecting callgraph data concerning the procedures it contains and the sites from which these procedures are called, identifying target procedures which are rarely or never called during normal execution or which do not return from a call, and recompiling the program to provide said executable 15 program, in reverse topological order to that indicated by the callgraph data, including any necessary code in target procedures such that register usage by such procedures can be and is ignored during recompilation a non-target procedure calling a target procedure.
The invention extends to a method of compiling a computer program from code modules of a high or intermediate level l~ngu~ge, to provide object code executable on a target computer having 20 hardware registers available for the storage of data used by the program during execution, comprising:
compiling the code modules, processing data, produced during at least one of compiling of the code modules and execution of an executable program produced by linking of the modules, to produce a call graph of procedures comprised by the program, and to identify target procedures ln the category of at least one of procedures rarely or never called during normal execution of the program and procedures which never return from a call;
recompiling the procedures, recompilation of identified target procedures being with the inclusion of code at the entry of the procedure to save all hardware registers modifiable thereby, and with the inclusion of code to restore the saved registers if the procedure returns, whereby said target procedures may be considered in compiling of procedures containing their callsites to use no hardware registers.
The invention also extends to apparatus for compiling computer programs to convert modular source code into object code executable upon a target computer, by a method according to the invention, which apparatus may contain a general purpose computer configured to carry out the method by the loading of a compiler program implementing the invention. The invention further extends to media recorded with a compiler program for so configuring a general purpose computer.
Unlike conventional optimization techniques, which are typically intraprocedural, ;mplementation of the present invention is dependent ~pOtl the relationships between procedures; thus a rarely or once used procedure is modified in a manner which reduces its performance in order to improve the performance of another procedure, more frequently used calling the modified procedure. To the extent that these interprocedural relation.sllip.s must be analyzed in order to apply the invention, it is ~iseful and convenient to apply the invention in conjunction wilh other optimization techniques which can utilize such an arlalysis, and the nature of the analysis may take this illtO account, as in the following example: however such other optimization techniques do not form part of the present inventiotl.
The invention is further clescribed with reference to the e 2 1 0 2 0 8 9 -.,A9-93-016 5 following description of an exemplary compiler incorporating the invention.
Brief Description of the Drawings Figure l is a block diagram of the structure of relevant portions of a compiler implementing the invention;
Figure 2 is graphical representation of the call graph of a simple program;
Figure 3 is graphical illustration of the operation of the present information applied to a callgraph;
and Figure 4 is a flow diagram illustrating the computer-implemented steps for practising the method of the invention; and Figure 5 on the same page as Figure 3, is a block diagram of apparatus used to implement the invention.
Detailed Description of the Preferred Embodiments In order to implement the present invention, a program must be compiled twice, first to provide information upon interprocedural relationships, and secondly to apply the information gathered.
The system incorporated in the compiler of Figure l is thus a two-pass system. The first pass, which is performed at compile time, collects summary information for each procedure compiled. The second pass, which is performed at link time, merges the collected information and uses it to compute an interprocedural solution for the entire application. The application is then rebuilt using the interprocedural solution to enhance optimization. In the example shown, a command option to 2 0 a compiler 2, upon its invocation to compile source code modules, causes it to collect interprocedural information about procedures which it compiles. A command option to a compiler loop module 4 (or a Linker could be used) upon its invocation to link object code produced by the compiler causes 2I ~2 0 .
the loop module to use the interprocedural information to recompile the modules with enhanced optimization, and link the interprocedurally optimized versions of object code to form a "golden" output file lO.
Information collection during compilation is triggered by the use of the designated command option. Summary information for the file and each procedure is collected during compilation and is written to the object file produced for use at link 6.
Each object file 6 is associated with an appropriately identified section containing the additional information.
This information could of course be collected in a separate file if more convenient.
This summary information includes:
The fully qualified source file name.
The name of each contained procedure (with sufficient information to avoid ambiguity).
The compiler options invoked.
A list of all callsites in each procedure, again with sufficient information to avoid any ambiguity in identification.
Constant propagation information for parameters at each callsite.
Alias information for each procedure.
Information as to suitability for other optimization techniques, i.e. inlining and cloning, such as intermediate language size, automatic storage usage, and constant parameters, for each procedure.
Callsite post-dominance information.
A measure of code motion out of loops as computed by the Morel-Reinvest and the common subexpressions algorithms.
2la,~3 Register pressure/coloring (usage) information.
When all files in the application have been compiled, the user invokes the compiler loop module 4 through the compiler, again with the command option mentioned above. The link time driver 8 reads the summary information from the object files 6 and, optionally, from a profiling sample 12 produced by running a profiler on an outE~tlt file produced by a previous linking of the object file 6, and computes the application's callgraph utilizing known callgraphing techniques.
For example, consider the application shown below:
File a.c: Eile b.c:
main() bar() .
foo(); foobar();
bar()'; }
} File c.:
foobar() foo() foo(); }
Figure 2 shows the callgraph for this example. Information that will allow the driver 8 to construct the application's callgraph is contained in each of the three object files. For enhanced optimization in the invention, the driver causes a bottom-up (reverse topological ordered) recompilation 14 of the application. In our example the ordering is a.c(foo), c.c(foobar), b.c(bar) and a.c(main). The optimizer is repetitively invoked, by the driver program, in this order once the interprocedural solution for the entire application has been computed.
~1~2~83 The interprocedural .solution is computed in several steps:
Alias information for each procedure is propagated upwards in the callgraph to the root.
Constant parameter information is propagated downwards in the callgraph to the leaves.
Profile information, if available, is read and callgraph edges are marked with traversal counts (see Fig. 3).
Heuristic algorithms are run to identify candidates for various optimization techniques, including that of the invention.
As each procedure in the application is recompiled, register usage information is saved and fed back into subsequent recompilations. It is useful for compilers designed for a particular hardware platform to respect conventions as to which available hardware registers may be modified by procedures as compiled. Eor example, in the RISC System/6000 target processor, linkage convention dictates that general purpose registers 9,1, and 3-1~, floating-point registers 0-13, condition registers 9, ~, 5, 6, and 7, and the count register are volatile. In the absence of information to the contrary, the caller must assume that the values contained in volatile registers are killed by the callee.
The compiler recompiles the application at link time in reverse topological callgraph order. Hence callee procedures will be recompiled before their callers. By storing information 26 about actual register usage in the callee in memory 28, the unaltered volatile registers are still available for use by the cal]er. This process may be referred to as register resurrection Register resurrection permits an application to make better ~1se of the available hardware ~1 ~2~Y
register file. The application should experience less storage traffic caused by reduced register save/restore code and reduced register spill code, that is traffic to and from the stack due to insufficient hardware registers being available to service a procedure.
Even when analysis determines that a reference to a procedure may invalidate register's contents, there may be a benefit to moving the register save-and-restore code that would otherwise be required in the calling procedure. This technique is beneficial where the procedure is known to be referenced only very rarely, such as debuggjng and error handling procedures.
-~~ For example:
-Preserve.f DO I=l,OOOOO
C ... Code that manipulates may scalars or arrays IF (Xl(I).GT.l.OE32) CALL ERRORl(Xl(I)) IF (xl(I).LT.O.lE-32) CALL ERROR2(Xl(I)) C ... Code that does some more with these scalars or arrays ENDDO
Without modification of the called procedures, the compiler ~ assumes that linkage-converltiorl volatile registers are invalidated by the referen(es to ERRORl and ERROR2, and so additional code may be generated to restore any values that were in registers before the references and that are required after the references. This additional code can reduce performance and increase the code size of the loop, which can - increase instruction cache miss delays. However, if ERRORl and ERROR2 are almost never called, the code to save and restore invalidated registers can be transferred into the procedures so that there is no need to reload the values within the referencing procedure. This is done by placing register saving code at the start of each procedure, and placing register restoring code at the end of the procedure.
21~2ass ~ - CA9-93-016 10 Eventhough this may result in a larger object file, instruction cache and proces.sor usage are improved because the - register-preserving code is almost never loaded into the instruction cache and is almost never executed.
Moving register save-and-restore code is useful for error-handling or range-checking procedures where the error or out-of-range value is found on]y rarely.
If a referenced procedure always terminates a program, there is no reason to invalida-te registers when the procedure is referenced. In the following C example, the standard function exit() is called within a conditional block. Normally, the compiler inserts code before and possibly after the call to exit() to save and restore any required registers that may be invalidated by the call.
int main(void) ~ ~ ~ /
for (i=O;i<lOOOO;i++) if (a[i]~10000.0) bailout(-1);
else a[il+=b[i]*cli]
}
* *
~ ~ ~
}
int bailout(int retcode) ~
printf("Error: ~5\n",msg[-retcode]);
exit(retcode);
}
The compiler does not know -Ihat exit() is a function that never returns, and that preserving the registers across the reference to bailout() is therefore pointless. This is also true for the C functions abort() and terminate()(or assert()) in the RISC System 6000 taryet environment, the Fortran STOP
statement, and other terminAtirlg procedures. The lin]~er can 2la2~3 be instructed to treat certain standard procedures as terminating procedures, by specifying an exits suboption.
This suboption does not allow terminating procedures.
However, the callgraph can establish that a procedure always calls a terminating procedure, and can propagate this information upwards in the calling chain so that registers are not preserved around references to terminating procedures, upon call of which the preservation of registering becomes immaterial.
However, the most beneficial application of the invention is in conjunction with profiling data feedback. Functions that are never called in a profiling sample 12 will be modified as described above, as may other functions that are called with less than a predetermined frequency. The profiling i information may be collected from a single run, or the usermay collect information from several typical runs. In any event, the sample obtained is considered to be representative of the running application and procedures for modification are selected accordingly. As seen in Figure 3, the inclusion of - profiling information in the callgraph enables procedures at boundaries between frequently called procedures 16 and rarely or never called procedures 18, 20, 22 to be modified as described above. It should be noted that application of the invention is only needed at the points where a frequently ; executed procedure calls an infrequently called procedure, since inherently the infrequently called procedure can only itself make infrequent calls.
Other optimization tec~miques benefit from the above use of profiling information, such as inlining and cloning. There is no benefit in inlining or cloning never called or infrequently called procedures. This a]lows more aggressive inlining or cloning of more highly used routines since concerns about code-size explosions caused by over-inlining will not become a factor as quickly. Figure 3 shows a generic callgraph whose edges are labelled, via profiling feedback, with the frequency they are traversed. With this information, modification of 2~02a89 the routines 18 and 20 isolates the entire subtree below the "firewalls" 24 erected hy sucll modification, which ensures that register usage by the producers 18, 20 and 22 is invisible to the procedures 16; this same information indicates that there is no benefit in applying inlining or cloning techniques to the call beyond the firewalls.
Once it has been determined necessary to construct a "firewall" in a code module, the generation steps set out in the schematic flow diagram of Figure 4 are followed.
Register allocation 40 is accomplished by passing the program code through a register al]ocation algorithm to compute the solutions for each disjoint class of registers on the target computer. A suitable register allocation algorithm is described, for example in an article: "Register Allocation and Spilling Via Graph Coloring:, by Chaitin et al, in Computer Language, 6:47-57, 1981.
The register allocal:ion 40 yields the register allocation output 42 for each register class.
Multiple passes of the regi.~ter allocation loop 40, 42 may be necessary to compute and allocate the solutions for all the register classes for the target machine. For example, in the RISC System/6000 target enviromnent, there are three classes of registers, so that three passes of the register allocation algorithm are required.
Followlng the register a]location for all classes of registers, code is generated in the prologue of the program 44 to reserve a portion of -the al1tomatic stack storage to hold all of tl~e modified volati]e registers. This stack storage is of course allocated at rl1ntime.
Then, for each modified register, code is generated in each module 46 as follows: code is ge1lerated in the prologue to implement a store of the proper widtil into the next available ~102~89 slot in the reserved storage, and is generated in the epilogue to implement a load of the proper width from the same slot in the reserved storage back into the same volatile register.
Each generated module in a computer program then includes:
Prologue Code Main code for module r~. . Epilogue Code Referring to Figure 5, the compiling method of the invention may be implemented utilizing a general purpose computer 30, which may be similar or dissimilar to the target computer of the compilation depending on whether a regular or cross-compiler is being implemented. The computer has a conventional console 32 providing a user interface, and conventional storage for both data 34 and programs 36. A
program 38 stored on suitable media is loaded into the computer's program storage to configure it as compiling apparatus. The data storage 34 may receive data input from a profiler 40 which may be imp]emented either utilizing the same computer or separately.
-- It should be understood that the compiler may accept as input --~ either a conventional high level language, or an intermediate language to which the high ~evel language has already been translated; the latter may be advantageous in that it permits many of the programs making up a compiler suite to be common to several different languages, which are translated to a common intermediate language by appropriate front end modules.
Claims (16)
1. A method for optimizing the compilation of a computer program written in a high level language to allow said computer program to be executable upon a target computer, comprising the steps of:
precompiling said computer program, which further comprises the steps of:
collecting call graph data concerning procedures performed by said computer program and sites from whence said procedures are called;
identifying target procedure that have a low-priority during normal execution of said computer program; and recompiling said computer program to provide an executable program further comprising the step of:
controlling register usage by said target procedures during recompilation by preserving registers for said target procedures so as to avoid conflict with any non-target procedure when said target procedure is called during execution of said computer program.
precompiling said computer program, which further comprises the steps of:
collecting call graph data concerning procedures performed by said computer program and sites from whence said procedures are called;
identifying target procedure that have a low-priority during normal execution of said computer program; and recompiling said computer program to provide an executable program further comprising the step of:
controlling register usage by said target procedures during recompilation by preserving registers for said target procedures so as to avoid conflict with any non-target procedure when said target procedure is called during execution of said computer program.
2. The method according to claim 1 wherein said low-priority target procedures are those procedures rarely called during normal execution of said computer program.
3. The method according to claim 1 wherein said low-priority target procedures include those target procedures that are never called during normal execution of said computer program, but are called during precompiling said program.
4. The method according to claim 1 wherein said low-priority target procedures are those that do not return from a call during normal execution of said computer program or during said precompiling of said program.
5. The method, according to claim 1, wherein said step of recompiling said program is performed in reverse topological order to that indicated by the callgraph data.
6. The method according to claim 1, further including the step of applying additional optimization techniques to that portion of the program formed by non-target procedures.
7. A method of compiling a computer program from a plurality of code modules of a high or intermediate level language, to provide object code executable on a target computer having hardware registers available for storage of data used by said computer program during execution, comprising the steps of:
compiling each of said plurality of code modules;
processing data from at least one of said compiled code modules and from an executable program produced by linking said code modules one to another;
producing a callgraph of procedures, based on said processed data, that are possible within said computer program;
identifying target procedures within a first group of procedures having a low-priority of being called by said computer program during normal execution; and recompiling said procedures and said target procedures having low priority so as to save all hardware registers modified by said low-priority target procedures so as to restore said saved registers upon exit from said low-priority target procedures during execution of said computer program.
compiling each of said plurality of code modules;
processing data from at least one of said compiled code modules and from an executable program produced by linking said code modules one to another;
producing a callgraph of procedures, based on said processed data, that are possible within said computer program;
identifying target procedures within a first group of procedures having a low-priority of being called by said computer program during normal execution; and recompiling said procedures and said target procedures having low priority so as to save all hardware registers modified by said low-priority target procedures so as to restore said saved registers upon exit from said low-priority target procedures during execution of said computer program.
8. The method according to claim 7 wherein said step of recompiling said procedures further comprises the step of coding said low-priority target procedures during said step of compiling of said procedures so that any call sites requested by said low-priority target procedures use no hardware registers.
9. The method, according to claim 7, wherein said low-priority target procedures include procedures whose call results in an exit from said computer program.
10. The method, according to claim 7, wherein said processed data includes data generated by running a profiler on an executable program produced by linking compiled modules, and said low-priority target procedures includes procedures identified by the profiler as rarely, if ever, called.
11. The method, according to claim 7, wherein the introduction of register saving and restoring code into a target procedure is performed by adding prologue and epilogue code to the code of the original procedure including the register saving and restoring code.
12. The method, according to claim 7, wherein the procedures are recompiled in reverse order to that in which they are called as shown in said callgraph, and recompilation of target procedures precedes recompilation of procedures containing call sites for said target procedures.
13. In an apparatus for compiling a computer program from a plurality of source code modules in a computer language to produce an executable program, comprising a programmable computer having a user interface, and data and program storage, the program storage holding a compiler program suite for execution on the computer, the compiler program suite comprising:
a compiler program module for compiling said plurality of source code modules and configuring said computer to generate data relating to each of said plurality of source code modules compiled including data identifying each procedure therein, callsites within each procedure, and register usage by each procedure;
a compiler loop module comprising:
means for accepting the data generated by the compiler program module to construct callgraph data;
means for modifying procedures contained in said plurality of source code modules comprising:
means for permitting identification of target procedures that will rarely or never be used during normal execution of the executable program;
means for modifying returning procedures by the insertion of code that saves and restores registers that may be modified by the target procedures;
means for recompiling said procedures in an order reversing topology defined by the callgraph data while storing in data memory storage details of hardware register usage whereby said recompiled procedure containing a callsite of a modified procedure may be recompiled without regard for hardware register modification by the called procedure; and means for linking the recompiled source code modules into an executable program.
a compiler program module for compiling said plurality of source code modules and configuring said computer to generate data relating to each of said plurality of source code modules compiled including data identifying each procedure therein, callsites within each procedure, and register usage by each procedure;
a compiler loop module comprising:
means for accepting the data generated by the compiler program module to construct callgraph data;
means for modifying procedures contained in said plurality of source code modules comprising:
means for permitting identification of target procedures that will rarely or never be used during normal execution of the executable program;
means for modifying returning procedures by the insertion of code that saves and restores registers that may be modified by the target procedures;
means for recompiling said procedures in an order reversing topology defined by the callgraph data while storing in data memory storage details of hardware register usage whereby said recompiled procedure containing a callsite of a modified procedure may be recompiled without regard for hardware register modification by the called procedure; and means for linking the recompiled source code modules into an executable program.
14. The apparatus according to claim 13, wherein said means for recompiling the procedures contained in the source code modules is adapted to recompile those procedures in an order reversing topography defined by the callgraph data.
15. The apparatus according to claim 13, wherein said means for permitting identification of target procedures includes a profiler.
16. The apparatus according to claim 13, wherein said means for permitting identification of target procedures includes means for recognizing procedures that lead only to termination of the program.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002102089A CA2102089C (en) | 1993-10-29 | 1993-10-29 | Recompilation of computer programs for enhanced optimization |
| JP18380294A JP3337174B2 (en) | 1993-10-29 | 1994-08-04 | Compilation method |
| EP94307568A EP0651327A3 (en) | 1993-10-29 | 1994-10-14 | Recompilation of computer programs for enhanced optimization |
| US08/598,065 US5768595A (en) | 1993-10-29 | 1996-02-07 | System and method for recompiling computer programs for enhanced optimization |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002102089A CA2102089C (en) | 1993-10-29 | 1993-10-29 | Recompilation of computer programs for enhanced optimization |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2102089A1 CA2102089A1 (en) | 1995-04-30 |
| CA2102089C true CA2102089C (en) | 1999-05-25 |
Family
ID=4152045
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002102089A Expired - Fee Related CA2102089C (en) | 1993-10-29 | 1993-10-29 | Recompilation of computer programs for enhanced optimization |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5768595A (en) |
| EP (1) | EP0651327A3 (en) |
| JP (1) | JP3337174B2 (en) |
| CA (1) | CA2102089C (en) |
Families Citing this family (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2166252C (en) * | 1995-12-28 | 1999-08-24 | Robert James Blainey | Global variable coalescing |
| CA2166253C (en) * | 1995-12-28 | 2000-02-08 | Robert James Blainey | Connectivity based program partitioning |
| JPH09274570A (en) * | 1996-04-08 | 1997-10-21 | Mitsubishi Electric Corp | Compile method and compiler system |
| US5937195A (en) * | 1996-11-27 | 1999-08-10 | Hewlett-Packard Co | Global control flow treatment of predicated code |
| US6016398A (en) * | 1997-04-01 | 2000-01-18 | Intel Corporation | Method for using static single assignment to color out artificial register dependencies |
| US6072951A (en) * | 1997-10-15 | 2000-06-06 | International Business Machines Corporation | Profile driven optimization of frequently executed paths with inlining of code fragment (one or more lines of code from a child procedure to a parent procedure) |
| US7337173B1 (en) * | 1997-12-04 | 2008-02-26 | Netscape Communications Corporation | Compiler having global element optimization |
| US6029000A (en) * | 1997-12-22 | 2000-02-22 | Texas Instruments Incorporated | Mobile communication system with cross compiler and cross linker |
| US6175956B1 (en) * | 1998-07-15 | 2001-01-16 | International Business Machines Corporation | Method and computer program product for implementing method calls in a computer system |
| US6195793B1 (en) * | 1998-07-22 | 2001-02-27 | International Business Machines Corporation | Method and computer program product for adaptive inlining in a computer system |
| US6983459B1 (en) * | 1999-04-06 | 2006-01-03 | International Business Machines Corporation | Incorporating register pressure into an inlining compiler |
| JP4462676B2 (en) * | 1999-10-27 | 2010-05-12 | 富士通株式会社 | Program conversion device, compiler device, and computer-readable recording medium recording program conversion program |
| US6862730B1 (en) * | 2000-04-26 | 2005-03-01 | Lucent Technologies Inc. | Register allocation in code translation between processors |
| US6658656B1 (en) * | 2000-10-31 | 2003-12-02 | Hewlett-Packard Development Company, L.P. | Method and apparatus for creating alternative versions of code segments and dynamically substituting execution of the alternative code versions |
| US7086044B2 (en) * | 2001-03-22 | 2006-08-01 | International Business Machines Corporation | Method, article of manufacture and apparatus for performing automatic intermodule call linkage optimization |
| US7017154B2 (en) * | 2001-03-23 | 2006-03-21 | International Business Machines Corporation | Eliminating store/restores within hot function prolog/epilogs using volatile registers |
| US7010785B2 (en) * | 2001-03-23 | 2006-03-07 | International Business Machines Corporation | Eliminating cold register store/restores within hot function prolog/epilogs |
| US7275242B2 (en) * | 2002-10-04 | 2007-09-25 | Hewlett-Packard Development Company, L.P. | System and method for optimizing a program |
| US7269827B2 (en) * | 2002-10-21 | 2007-09-11 | Intel Corporation | Method and apparatus for compiling code |
| US7120898B2 (en) | 2003-06-26 | 2006-10-10 | Microsoft Corporation | Intermediate representation for multiple exception handling models |
| US7146606B2 (en) * | 2003-06-26 | 2006-12-05 | Microsoft Corporation | General purpose intermediate representation of software for software development tools |
| US7685581B2 (en) * | 2003-06-27 | 2010-03-23 | Microsoft Corporation | Type system for representing and checking consistency of heterogeneous program components during the process of compilation |
| US7559050B2 (en) * | 2003-06-30 | 2009-07-07 | Microsoft Corporation | Generating software development tools via target architecture specification |
| US7086041B2 (en) * | 2003-06-27 | 2006-08-01 | Microsoft Corporation | Extensible type system for representing and checking consistency of program components during the process of compilation |
| US7707566B2 (en) | 2003-06-26 | 2010-04-27 | Microsoft Corporation | Software development infrastructure |
| US7305666B2 (en) * | 2003-07-23 | 2007-12-04 | Microsoft Corporation | Description language for an extensible compiler and tools infrastructure |
| US7788652B2 (en) * | 2003-06-27 | 2010-08-31 | Microsoft Corporation | Representing type information in a compiler and programming tools framework |
| US7661095B2 (en) * | 2005-04-14 | 2010-02-09 | Hewlett-Packard Development Company, L.P. | System and method to build a callgraph for functions with multiple entry points |
| US7493602B2 (en) * | 2005-05-02 | 2009-02-17 | International Business Machines Corporation | Methods and arrangements for unified program analysis |
| US20070089104A1 (en) * | 2005-10-13 | 2007-04-19 | Arie Tal | Method and system for managing heuristic properties |
| US7987452B2 (en) * | 2005-12-15 | 2011-07-26 | International Business Machines Corporation | Profile-driven lock handling |
| WO2007095642A2 (en) * | 2006-02-16 | 2007-08-23 | The Regents Of The University Of California | Dynamic incremental compiler and method |
| US8117604B2 (en) * | 2006-07-31 | 2012-02-14 | International Business Machines Corporation | Architecture cloning for power PC processors |
| US8370821B2 (en) * | 2007-08-21 | 2013-02-05 | International Business Machines Corporation | Method for enabling profile-based call site tailor-ing using profile gathering of cloned functions |
| US8473935B2 (en) * | 2008-04-21 | 2013-06-25 | Microsoft Corporation | Just-ahead-of-time compilation |
| US8522218B2 (en) * | 2010-03-12 | 2013-08-27 | Microsoft Corporation | Cross-module inlining candidate identification |
| JP6080602B2 (en) | 2013-02-22 | 2017-02-15 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | Real footprint calculation method, method for determining inline method using the calculation method, apparatus and program |
| US9027007B2 (en) * | 2013-03-06 | 2015-05-05 | Qualcomm Incorporated | Reducing excessive compilation times |
| US9996325B2 (en) | 2013-03-06 | 2018-06-12 | Qualcomm Incorporated | Dynamic reconfigurable compiler |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5428793A (en) * | 1989-11-13 | 1995-06-27 | Hewlett-Packard Company | Method and apparatus for compiling computer programs with interproceduural register allocation |
| US5301325A (en) * | 1991-03-07 | 1994-04-05 | Digital Equipment Corporation | Use of stack depth to identify architechture and calling standard dependencies in machine code |
| US5339238A (en) * | 1991-03-07 | 1994-08-16 | Benson Thomas R | Register usage tracking in translating code for different machine architectures by forward and reverse tracing through the program flow graph |
| US5339428A (en) * | 1991-09-04 | 1994-08-16 | Digital Equipment Corporation | Compiler allocating a register to a data item used between a use and store of another data item previously allocated to the register |
-
1993
- 1993-10-29 CA CA002102089A patent/CA2102089C/en not_active Expired - Fee Related
-
1994
- 1994-08-04 JP JP18380294A patent/JP3337174B2/en not_active Expired - Fee Related
- 1994-10-14 EP EP94307568A patent/EP0651327A3/en not_active Withdrawn
-
1996
- 1996-02-07 US US08/598,065 patent/US5768595A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US5768595A (en) | 1998-06-16 |
| EP0651327A2 (en) | 1995-05-03 |
| JPH07129412A (en) | 1995-05-19 |
| CA2102089A1 (en) | 1995-04-30 |
| JP3337174B2 (en) | 2002-10-21 |
| EP0651327A3 (en) | 1995-06-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2102089C (en) | Recompilation of computer programs for enhanced optimization | |
| US5768596A (en) | System and method to efficiently represent aliases and indirect memory operations in static single assignment form during compilation | |
| Krall | Efficient JavaVM just-in-time compilation | |
| Suganuma et al. | A dynamic optimization framework for a Java just-in-time compiler | |
| US6072951A (en) | Profile driven optimization of frequently executed paths with inlining of code fragment (one or more lines of code from a child procedure to a parent procedure) | |
| US7725883B1 (en) | Program interpreter | |
| US6173444B1 (en) | Optimizing compilation of pointer variables in the presence of indirect function calls | |
| EP0428084B1 (en) | Method and apparatus for compiling computer programs with interprocedural register allocation | |
| Agesen et al. | Garbage collection and local variable type-precision and liveness in Java virtual machines | |
| US8769511B2 (en) | Dynamic incremental compiler and method | |
| US5761514A (en) | Register allocation method and apparatus for truncating runaway lifetimes of program variables in a computer system | |
| US7308682B2 (en) | Method and apparatus for recovering data values in dynamic runtime systems | |
| Jagannathan et al. | Flow-directed inlining | |
| US20080082972A1 (en) | Automatic customization of classes | |
| Chambers et al. | Whole-program optimization of object-oriented languages | |
| Davidson et al. | An aggressive approach to loop unrolling | |
| US6647546B1 (en) | Avoiding gather and scatter when calling Fortran 77 code from Fortran 90 code | |
| Suganuma et al. | A region-based compilation technique for dynamic compilers | |
| US6665864B1 (en) | Method and apparatus for generating code for array range check and method and apparatus for versioning | |
| Whaley | Dynamic optimization through the use of automatic runtime specialization | |
| Steindl | Intermodular slicing of object-oriented programs | |
| US7240341B2 (en) | Global constant pool to allow deletion of constant pool entries | |
| Wall | Experience with a software-defined machine architecture | |
| Dean et al. | Training compilers for better inlining decisions | |
| Saleil | Simple Optimizing JIT Compilation of Higher-Order Dynamic Programming Languages |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |