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