[llvm-commits] CVS: llvm/docs/LLVMVsTheWorld.html

Wed Nov 12 14:20:02 PST 2003

Changes in directory llvm/docs:

LLVMVsTheWorld.html added (r1.1)

---
Log message:

First draft of LLVM-to-anything comparison document.

---
Diffs of the changes:  (+178 -0)

Index: llvm/docs/LLVMVsTheWorld.html
diff -c /dev/null llvm/docs/LLVMVsTheWorld.html:1.1
*** /dev/null	Wed Nov 12 14:19:51 2003
--- llvm/docs/LLVMVsTheWorld.html	Wed Nov 12 14:19:40 2003
***************
*** 0 ****
--- 1,178 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+                       "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+   <link rel="stylesheet" href="llvm.css" type="text/css">
+   <title>LLVM vs. the World - Comparing Compilers to Compilers</title>
+ </head>
+ 
+ <body>
+ 
+ <div class="doc_title">
+   LLVM vs. the World - Comparing Compilers to Compilers
+ </div>
+ 
+ <ol>
+   <li><a href="#introduction">Introduction</a></li>
+   <li><a href="#generalapplicability">General Applicability</a></li>
+   <li><a href="#typesystem">Type System</a></li>
+   <li><a href="#dataflowinformation">Control-flow and Data-flow Information</a></li>
+   <li><a href="#registers">Registers</a></li>
+   <li><a href="#programmerinterface">Programmer Interface</a></li>
+   <li><a href="#codeemission">Machine Code Emission</a></li>
+ </ol>
+ 
+ <div class="doc_text">    
+   <p><b>Written by Brian R. Gaeke</b></p>
+ </div>
+ 
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+   <a name="introduction">Introduction</a>
+ </div>
+ <!-- *********************************************************************** -->
+ 
+ <div class="doc_text">
+ <p>Whether you are a stranger to LLVM or not, and whether you are considering
+ using it for your projects or not, you may find it useful to understand how we
+ compare ourselves to other well-known compilers. The following list of points
+ should help you understand -- from our point of view -- the way we see LLVM as
+ being better than and/or different from a few other selected compilers and code
+ generation systems.</p>
+ 
+ <p>At the moment, we only compare ourselves below to <a
+ href="http://gcc.gnu.org/">GCC</a> and <a
+ href="http://www.gnu.org/software/lightning/">GNU lightning</a>, but we will try
+ to revise and expand it as our knowledge and experience permit. Contributions are
+ welcome.</p>
+ </div>
+ 
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+   <a name="generalapplicability">General Applicability</a>
+ </div>
+ <!-- *********************************************************************** -->
+ 
+ <div class="doc_text">
+ <p>GNU lightning: Only currently usable for dynamic runtime emission of binary
+ machine code to memory. Supports one backend at a time.</p>
+ 
+ <p>LLVM: Supports compilation of C and C++ (with more languages coming soon),
+ strong SSA-based optimization at compile-time, link-time, run-time, and
+ off-line, and multiple platform backends with Just-in-Time and ahead-of-time
+ compilation frameworks. (See our tech report on <a
+ href="http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html">Lifelong
+ Code Optimization</a> for more.)</p>
+ </div>
+ 
+ <p>GCC: Many relatively mature platform backends support assembly-language code
+ generation from many source languages. No run-time compilation
+ support. Relatively weak optimization support.</p>
+ 
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+   <a name="typesystem">Type System</a>
+ </div>
+ <!-- *********************************************************************** -->
+ 
+ <div class="doc_text">
+ <p>GNU lightning: C integer types and "void *" are supported. No type checking
+ is performed. Explicit type casts are not typically necessary unless the
+ underlying machine-specific types are distinct (e.g., sign- or zero-extension is
+ apparently necessary, but casting "int" to "void *" would not be.) No floating
+ point (?!)</p>
+ 
+ <p>LLVM: Compositional type system based on C types, supporting structures,
+ opaque types, and C integer and floating point types.</p>
+ 
+ <p>GCC: Union of high-level types including those used in Pascal, C, C++, Ada,
+ Java, and FORTRAN.</p>
+ </div>
+ 
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+   <a name="dataflowinformation">Control-flow and Data-flow Information</a>
+ </div>
+ <!-- *********************************************************************** -->
+ 
+ <div class="doc_text">
+ <p>GNU lightning: No data-flow information encoded in the generated program. No
+ support for calculating CFG or def-use chains over generated programs.</p>
+ 
+ <p>LLVM: Scalar values in Static Single-Assignment form; def-use chains and CFG
+ always implicitly available and automatically kept up to date.</p>
+ 
+ <p>GCC: Trees and RTL do not directly encode data-flow info; but def-use chains
+ and CFGs can be calculated on the side. They are not automatically kept up to
+ date.</p>
+ </div>
+ 
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+   <a name="registers">Registers</a>
+ </div>
+ <!-- *********************************************************************** -->
+ 
+ <div class="doc_text">
+ <p>GNU lightning: Very small fixed register set -- it takes the least common
+ denominator of supported platforms; basically it inherits its tiny register set
+ from IA-32, unnecessarily crippling targets like PowerPC with a large register
+ set.</p>
+ 
+ <p>LLVM: An infinite register set, reduced to a particular platform's finite
+ register set by register allocator.</p>
+ 
+ <p>GCC: Trees and RTL provide an arbitrarily large set of values.  Reduced to a
+ particular platform's finite register set by register allocator.</p>
+ </div>
+ 
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+   <a name="programmerinterface">Programmer Interface</a>
+ </div>
+ <!-- *********************************************************************** -->
+ 
+ <div class="doc_text">
+ <p>GNU lightning: Library interface based on C preprocessor macros that emit
+ binary code for a particular instruction to memory. No support for manipulating
+ code before emission.</p>
+ 
+ <p>LLVM: Library interface based on classes representing platform-independent
+ intermediate code (Instruction) and platform-dependent code (MachineInstr) which
+ can be manipulated arbitrarily and then emitted to memory.</p>
+ 
+ <p>GCC: Internal header file interface (tree.h) to abstract syntax trees,
+ representing roughly the union of all possible supported source-language
+ constructs; also, an internal header file interface (rtl.h, rtl.def) to a
+ low-level IR called RTL which represents roughly the union of all possible
+ target machine instructions.</p>
+ </div>
+ 
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+   <a name="codeemission">Machine Code Emission</a>
+ </div>
+ <!-- *********************************************************************** -->
+ 
+ <div class="doc_text">
+ <p>GNU lightning: Only supports binary machine code emission to memory.</p>
+ 
+ <p>LLVM: Supports writing out assembly language to a file, and binary machine
+ code to memory, from the same back-end.</p>
+ 
+ <p>GCC: Supports writing out assembly language to a file. No support for
+ emitting machine code to memory.</p>
+ </div>
+ 
+ <!-- *********************************************************************** -->
+ 
+ <hr>
+ <div class="doc_footer">
+   <address>Brian R. Gaeke</address>
+   <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+   <br>
+   Last modified: $Date: 2003/11/12 20:19:40 $
+ </div>
+ 
+ </body>
+ </html>