]> git.proxmox.com Git - rustc.git/blame - src/llvm/docs/HistoricalNotes/2001-04-16-DynamicCompilation.txt
Imported Upstream version 1.0.0+dfsg1
[rustc.git] / src / llvm / docs / HistoricalNotes / 2001-04-16-DynamicCompilation.txt
CommitLineData
223e47cc
LB
1By Chris:
2
3LLVM has been designed with two primary goals in mind. First we strive to
4enable the best possible division of labor between static and dynamic
5compilers, and second, we need a flexible and powerful interface
6between these two complementary stages of compilation. We feel that
7providing a solution to these two goals will yield an excellent solution
8to the performance problem faced by modern architectures and programming
9languages.
10
11A key insight into current compiler and runtime systems is that a
12compiler may fall in anywhere in a "continuum of compilation" to do its
13job. On one side, scripting languages statically compile nothing and
14dynamically compile (or equivalently, interpret) everything. On the far
15other side, traditional static compilers process everything statically and
16nothing dynamically. These approaches have typically been seen as a
17tradeoff between performance and portability. On a deeper level, however,
18there are two reasons that optimal system performance may be obtained by a
19system somewhere in between these two extremes: Dynamic application
20behavior and social constraints.
21
22From a technical perspective, pure static compilation cannot ever give
23optimal performance in all cases, because applications have varying dynamic
24behavior that the static compiler cannot take into consideration. Even
25compilers that support profile guided optimization generate poor code in
26the real world, because using such optimization tunes that application
27to one particular usage pattern, whereas real programs (as opposed to
28benchmarks) often have several different usage patterns.
29
30On a social level, static compilation is a very shortsighted solution to
31the performance problem. Instruction set architectures (ISAs) continuously
32evolve, and each implementation of an ISA (a processor) must choose a set
33of tradeoffs that make sense in the market context that it is designed for.
34With every new processor introduced, the vendor faces two fundamental
35problems: First, there is a lag time between when a processor is introduced
36to when compilers generate quality code for the architecture. Secondly,
37even when compilers catch up to the new architecture there is often a large
38body of legacy code that was compiled for previous generations and will
39not or can not be upgraded. Thus a large percentage of code running on a
40processor may be compiled quite sub-optimally for the current
41characteristics of the dynamic execution environment.
42
43For these reasons, LLVM has been designed from the beginning as a long-term
44solution to these problems. Its design allows the large body of platform
45independent, static, program optimizations currently in compilers to be
46reused unchanged in their current form. It also provides important static
47type information to enable powerful dynamic and link time optimizations
48to be performed quickly and efficiently. This combination enables an
49increase in effective system performance for real world environments.