docs/LLVMVsTheWorld.html - platform/external/llvm - Gitiles

 <!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 -- some of the important
 ways in which we see LLVM as different from 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>

 <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>

 <!-- *********************************************************************** -->
 <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.)
 Floating-point support may not work on all platforms (it does not appear to be
 documented in the latest release).</p>

 <p>LLVM: Compositional type system based on C types, supporting structures,
 opaque types, and C integer and floating point types. Explicit cast instructions
 are required to transform a value from one type to another.</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$
 </div>

 </body>
 </html>
	<!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 -- some of the important
	ways in which we see LLVM as different from 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>

	<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>

	<!-- *********************************************************************** -->
	<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.)
	Floating-point support may not work on all platforms (it does not appear to be
	documented in the latest release).</p>

	<p>LLVM: Compositional type system based on C types, supporting structures,
	opaque types, and C integer and floating point types. Explicit cast instructions
	are required to transform a value from one type to another.</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$
	</div>

	</body>
	</html>