llvm/docs/HistoricalNotes/2001-01-31-UniversalIRIdea.txt

   1 Date: Wed, 31 Jan 2001 12:04:33 -0600
   2 From: Vikram S. Adve <vadve@cs.uiuc.edu>
   3 To: Chris Lattner <lattner@cs.uiuc.edu>
   4 Subject: another thought
   5
   6 I have a budding idea about making LLVM a little more ambitious: a
   7 customizable runtime system that can be used to implement language-specific
   8 virtual machines for many different languages.  E.g., a C vm, a C++ vm, a
   9 Java vm, a Lisp vm, ..
  10
  11 The idea would be that LLVM would provide a standard set of runtime features
  12 (some low-level like standard assembly instructions with code generation and
  13 static and runtime optimization; some higher-level like type-safety and
  14 perhaps a garbage collection library).  Each language vm would select the
  15 runtime features needed for that language, extending or customizing them as
  16 needed.  Most of the machine-dependent code-generation and optimization
  17 features as well as low-level machine-independent optimizations (like PRE)
  18 could be provided by LLVM and should be sufficient for any language,
  19 simplifying the language compiler.  (This would also help interoperability
  20 between languages.)  Also, some or most of the higher-level
  21 machine-independent features like type-safety and access safety should be
  22 reusable by different languages, with minor extensions.  The language
  23 compiler could then focus on language-specific analyses and optimizations.
  24
  25 The risk is that this sounds like a universal IR -- something that the
  26 compiler community has tried and failed to develop for decades, and is
  27 universally skeptical about.  No matter what we say, we won't be able to
  28 convince anyone that we have a universal IR that will work.  We need to
  29 think about whether LLVM is different or if has something novel that might
  30 convince people.  E.g., the idea of providing a package of separable
  31 features that different languages select from.  Also, using SSA with or
  32 without type-safety as the intermediate representation.
  33
  34 One interesting starting point would be to discuss how a JVM would be
  35 implemented on top of LLVM a bit more.  That might give us clues on how to
  36 structure LLVM to support one or more language VMs.
  37
  38 --Vikram
  39