next up previous
Next: Static Properties of Functions Up: Limitations and Future Work Previous: Limitations and Future Work

Multiple Compilation Units

Currently, our implementation is unable to analyze calls to functions which are defined in another compilation unit (e.g. in a different source file). When the method encounters a case of this, it will treat the functions being called as unreusable, which potentially makes the results to be too conservative.

A solution to this problem can be developed by first dividing the functions defined in a different compilation unit into two categories:

  1. Functions defined in a different compilation unit that will be linked to a single executable during runtime.
  2. Functions defined in a dynamically loaded library.

We can extend our method to account for the first category of functions by doing partial analysis during compilation of a single compilation unit, and doing full analysis during link time. This is similar to the method of constructing call graph for functions in separate compilation units described in [10]. However, there are details of this method that will need to be worked out, which are beyond the scope of this paper.

The second category of functions present a more difficult case. In most cases, the programmers do not even have access to the source of functions defined in a dynamically loaded library. And since these functions are resolved fully only during the execution of the program, even if they are annotated as such, the optimization based on their annotations might be possible only during runtime. This is within the scope of dynamic compilation. And even if we can obtain the information when the functions are resolved partially during link time, we might still need to modify the executable/library format to accommodate for the annotations.


next up previous
Next: Static Properties of Functions Up: Limitations and Future Work Previous: Limitations and Future Work
Indrayana Rustandi 2003-12-04