|
150
|
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.
|
