llvm/docs/HistoricalNotes/2001-04-16-DynamicCompilation.txt

   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.