Dan Gohman | f17a25c | 2007-07-18 16:29:46 +0000 | [diff] [blame^] | 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. |