Gitiles
Code Review Sign In
gerrit-public.fairphone.software / toolchain / llvm-project / 6e6514c47eb140cf73009133b2e352d535cfe1be / . / llvm / docs / LLVMVsTheWorld.html
blob: c4fa6547c17a4936473c743fd864e2f28a7d4670 [file] [log] [blame]
Brian Gaeke63dbb1f2003-11-12 20:19:40 +0000[diff] [blame]1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
2 "http://www.w3.org/TR/html4/strict.dtd">
3<html>
4<head>
5 <link rel="stylesheet" href="llvm.css" type="text/css">
6 <title>LLVM vs. the World - Comparing Compilers to Compilers</title>
7</head>
8
9<body>
10
11<div class="doc_title">
12 LLVM vs. the World - Comparing Compilers to Compilers
13</div>
14
15<ol>
16 <li><a href="#introduction">Introduction</a></li>
17 <li><a href="#generalapplicability">General Applicability</a></li>
18 <li><a href="#typesystem">Type System</a></li>
19 <li><a href="#dataflowinformation">Control-flow and Data-flow Information</a></li>
20 <li><a href="#registers">Registers</a></li>
21 <li><a href="#programmerinterface">Programmer Interface</a></li>
22 <li><a href="#codeemission">Machine Code Emission</a></li>
23</ol>
24
Chris Lattner020e1fc2004-05-23 21:07:27 +0000[diff] [blame]25<div class="doc_author">
26 <p>Written by Brian R. Gaeke</p>
Brian Gaeke63dbb1f2003-11-12 20:19:40 +0000[diff] [blame]27</div>
28
29<!-- *********************************************************************** -->
30<div class="doc_section">
31 <a name="introduction">Introduction</a>
32</div>
33<!-- *********************************************************************** -->
34
35<div class="doc_text">
36<p>Whether you are a stranger to LLVM or not, and whether you are considering
37using it for your projects or not, you may find it useful to understand how we
38compare ourselves to other well-known compilers. The following list of points
Brian Gaekec806b222003-11-12 21:36:29 +0000[diff] [blame]39should help you understand -- from our point of view -- some of the important
40ways in which we see LLVM as different from other selected compilers and
41code generation systems.</p>
Brian Gaeke63dbb1f2003-11-12 20:19:40 +0000[diff] [blame]42
43<p>At the moment, we only compare ourselves below to <a
44href="http://gcc.gnu.org/">GCC</a> and <a
45href="http://www.gnu.org/software/lightning/">GNU lightning</a>, but we will try
46to revise and expand it as our knowledge and experience permit. Contributions are
47welcome.</p>
48</div>
49
50<!-- *********************************************************************** -->
51<div class="doc_section">
52 <a name="generalapplicability">General Applicability</a>
53</div>
54<!-- *********************************************************************** -->
55
56<div class="doc_text">
57<p>GNU lightning: Only currently usable for dynamic runtime emission of binary
58machine code to memory. Supports one backend at a time.</p>
59
60<p>LLVM: Supports compilation of C and C++ (with more languages coming soon),
61strong SSA-based optimization at compile-time, link-time, run-time, and
62off-line, and multiple platform backends with Just-in-Time and ahead-of-time
Chris Lattner132f6bb2004-02-22 05:45:02 +0000[diff] [blame]63compilation frameworks. (See our document on <a
64href="http://llvm.cs.uiuc.edu/pubs/2004-01-30-CGO-LLVM.html">Lifelong
Brian Gaeke63dbb1f2003-11-12 20:19:40 +0000[diff] [blame]65Code Optimization</a> for more.)</p>
Brian Gaeke63dbb1f2003-11-12 20:19:40 +0000[diff] [blame]66
67<p>GCC: Many relatively mature platform backends support assembly-language code
68generation from many source languages. No run-time compilation
Brian Gaeke07661262004-03-09 07:20:26 +0000[diff] [blame]69support.</p>
Brian Gaeke3bac7622003-11-12 20:20:55 +0000[diff] [blame]70</div>
Brian Gaeke63dbb1f2003-11-12 20:19:40 +0000[diff] [blame]71
72<!-- *********************************************************************** -->
73<div class="doc_section">
74 <a name="typesystem">Type System</a>
75</div>
76<!-- *********************************************************************** -->
77
78<div class="doc_text">
79<p>GNU lightning: C integer types and "void *" are supported. No type checking
80is performed. Explicit type casts are not typically necessary unless the
81underlying machine-specific types are distinct (e.g., sign- or zero-extension is
Brian Gaekee1fd80a2003-11-12 21:38:50 +0000[diff] [blame]82apparently necessary, but casting "int" to "void *" would not be.)
83Floating-point support may not work on all platforms (it does not appear to be
84documented in the latest release).</p>
Brian Gaeke63dbb1f2003-11-12 20:19:40 +0000[diff] [blame]85
86<p>LLVM: Compositional type system based on C types, supporting structures,
Brian Gaeke0afc4342003-11-12 21:39:31 +0000[diff] [blame]87opaque types, and C integer and floating point types. Explicit cast instructions
88are required to transform a value from one type to another.</p>
Brian Gaeke63dbb1f2003-11-12 20:19:40 +0000[diff] [blame]89
90<p>GCC: Union of high-level types including those used in Pascal, C, C++, Ada,
91Java, and FORTRAN.</p>
92</div>
93
94<!-- *********************************************************************** -->
95<div class="doc_section">
96 <a name="dataflowinformation">Control-flow and Data-flow Information</a>
97</div>
98<!-- *********************************************************************** -->
99
100<div class="doc_text">
101<p>GNU lightning: No data-flow information encoded in the generated program. No
102support for calculating CFG or def-use chains over generated programs.</p>
103
104<p>LLVM: Scalar values in Static Single-Assignment form; def-use chains and CFG
105always implicitly available and automatically kept up to date.</p>
106
107<p>GCC: Trees and RTL do not directly encode data-flow info; but def-use chains
108and CFGs can be calculated on the side. They are not automatically kept up to
109date.</p>
110</div>
111
112<!-- *********************************************************************** -->
113<div class="doc_section">
114 <a name="registers">Registers</a>
115</div>
116<!-- *********************************************************************** -->
117
118<div class="doc_text">
119<p>GNU lightning: Very small fixed register set -- it takes the least common
120denominator of supported platforms; basically it inherits its tiny register set
121from IA-32, unnecessarily crippling targets like PowerPC with a large register
122set.</p>
123
124<p>LLVM: An infinite register set, reduced to a particular platform's finite
125register set by register allocator.</p>
126
127<p>GCC: Trees and RTL provide an arbitrarily large set of values. Reduced to a
128particular platform's finite register set by register allocator.</p>
129</div>
130
131<!-- *********************************************************************** -->
132<div class="doc_section">
133 <a name="programmerinterface">Programmer Interface</a>
134</div>
135<!-- *********************************************************************** -->
136
137<div class="doc_text">
138<p>GNU lightning: Library interface based on C preprocessor macros that emit
139binary code for a particular instruction to memory. No support for manipulating
140code before emission.</p>
141
142<p>LLVM: Library interface based on classes representing platform-independent
143intermediate code (Instruction) and platform-dependent code (MachineInstr) which
144can be manipulated arbitrarily and then emitted to memory.</p>
145
146<p>GCC: Internal header file interface (tree.h) to abstract syntax trees,
147representing roughly the union of all possible supported source-language
148constructs; also, an internal header file interface (rtl.h, rtl.def) to a
149low-level IR called RTL which represents roughly the union of all possible
150target machine instructions.</p>
151</div>
152
153<!-- *********************************************************************** -->
154<div class="doc_section">
155 <a name="codeemission">Machine Code Emission</a>
156</div>
157<!-- *********************************************************************** -->
158
159<div class="doc_text">
160<p>GNU lightning: Only supports binary machine code emission to memory.</p>
161
162<p>LLVM: Supports writing out assembly language to a file, and binary machine
163code to memory, from the same back-end.</p>
164
165<p>GCC: Supports writing out assembly language to a file. No support for
166emitting machine code to memory.</p>
167</div>
168
169<!-- *********************************************************************** -->
170
171<hr>
172<div class="doc_footer">
173 <address>Brian R. Gaeke</address>
174 <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
175 <br>
176 Last modified: $Date$
177</div>
178
179</body>
180</html>