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