docs/ReleaseNotes.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   2                       "http://www.w3.org/TR/html4/strict.dtd">
   3 <html>
   4 <head>
   5   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   6   <link rel="stylesheet" href="llvm.css" type="text/css">
   7   <title>LLVM 2.7 Release Notes</title>
   8 </head>
   9 <body>
  10
  11 <div class="doc_title">LLVM 2.7 Release Notes</div>
  12
  13 <img align=right src="http://llvm.org/img/DragonSmall.png"
  14     width="136" height="136">
  15
  16 <ol>
  17   <li><a href="#intro">Introduction</a></li>
  18   <li><a href="#subproj">Sub-project Status Update</a></li>
  19   <li><a href="#externalproj">External Projects Using LLVM 2.7</a></li>
  20   <li><a href="#whatsnew">What's New in LLVM 2.7?</a></li>
  21   <li><a href="GettingStarted.html">Installation Instructions</a></li>
  22   <li><a href="#portability">Portability and Supported Platforms</a></li>
  23   <li><a href="#knownproblems">Known Problems</a></li>
  24   <li><a href="#additionalinfo">Additional Information</a></li>
  25 </ol>
  26
  27 <div class="doc_author">
  28   <p>Written by the <a href="http://llvm.org">LLVM Team</a></p>
  29 </div>
  30
  31 <!--
  32 <h1 style="color:red">These are in-progress notes for the upcoming LLVM 2.8
  33 release.<br>
  34 You may prefer the
  35 <a href="http://llvm.org/releases/2.6/docs/ReleaseNotes.html">LLVM 2.7
  36 Release Notes</a>.</h1>-->
  37
  38 <!-- *********************************************************************** -->
  39 <div class="doc_section">
  40   <a name="intro">Introduction</a>
  41 </div>
  42 <!-- *********************************************************************** -->
  43
  44 <div class="doc_text">
  45
  46 <p>This document contains the release notes for the LLVM Compiler
  47 Infrastructure, release 2.7.  Here we describe the status of LLVM, including
  48 major improvements from the previous release and significant known problems.
  49 All LLVM releases may be downloaded from the <a
  50 href="http://llvm.org/releases/">LLVM releases web site</a>.</p>
  51
  52 <p>For more information about LLVM, including information about the latest
  53 release, please check out the <a href="http://llvm.org/">main LLVM
  54 web site</a>.  If you have questions or comments, the <a
  55 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM Developer's
  56 Mailing List</a> is a good place to send them.</p>
  57
  58 <p>Note that if you are reading this file from a Subversion checkout or the
  59 main LLVM web page, this document applies to the <i>next</i> release, not the
  60 current one.  To see the release notes for a specific release, please see the
  61 <a href="http://llvm.org/releases/">releases page</a>.</p>
  62
  63 </div>
  64
  65
  66 <!--
  67 Almost dead code.
  68   include/llvm/Analysis/LiveValues.h => Dan
  69   lib/Transforms/IPO/MergeFunctions.cpp => consider for 2.8.
  70   llvm/Analysis/PointerTracking.h => Edwin wants this, consider for 2.8.
  71   ABCD, GEPSplitterPass
  72   MSIL backend?
  73   lib/Transforms/Utils/SSI.cpp  -> ABCD depends on it.
  74 -->
  75
  76
  77 <!-- Features that need text if they're finished for 2.7:
  78   combiner-aa?
  79   strong phi elim
  80   llvm.dbg.value: variable debug info for optimized code
  81   loop dependence analysis
  82  -->
  83
  84  <!-- for announcement email:
  85  Logo web page.
  86  llvm devmtg
  87  compiler_rt
  88  KLEE web page at klee.llvm.org
  89  Many new papers added to /pubs/
  90  Mention gcc plugin.
  91    -->
  92
  93 <!-- *********************************************************************** -->
  94 <div class="doc_section">
  95   <a name="subproj">Sub-project Status Update</a>
  96 </div>
  97 <!-- *********************************************************************** -->
  98
  99 <div class="doc_text">
 100 <p>
 101 The LLVM 2.7 distribution currently consists of code from the core LLVM
 102 repository (which roughly includes the LLVM optimizers, code generators
 103 and supporting tools), the Clang repository and the llvm-gcc repository.  In
 104 addition to this code, the LLVM Project includes other sub-projects that are in
 105 development.  Here we include updates on these subprojects.
 106 </p>
 107
 108 </div>
 109
 110
 111 <!--=========================================================================-->
 112 <div class="doc_subsection">
 113 <a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
 114 </div>
 115
 116 <div class="doc_text">
 117
 118 <p>The <a href="http://clang.llvm.org/">Clang project</a> is ...</p>
 119
 120 <p>In the LLVM 2.7 time-frame, the Clang team has made many improvements:</p>
 121
 122 <ul>
 123 <li>FIXME: C++! Include a link to cxx_compatibility.html</li>
 124
 125 <li>FIXME: Static Analyzer improvements?</li>
 126
 127 <li>CIndex API and Python bindings: Clang now includes a C API as part of the
 128 CIndex library. Although we make make some changes to the API in the future, it
 129 is intended to be stable and has been designed for use by external projects. See
 130 the Clang
 131 doxygen <a href="http://clang.llvm.org/doxygen/group__CINDEX.html">CIndex</a>
 132 documentation for more details. The CIndex API also includings an preliminary
 133 set of Python bindings.</li>
 134
 135 <li>ARM Support: Clang now has ABI support for both the Darwin and Linux ARM
 136 ABIs. Coupled with many improvements to the LLVM ARM backend, Clang is now
 137 suitable for use as a a beta quality ARM compiler.</li>
 138 </ul>
 139 </div>
 140
 141 <!--=========================================================================-->
 142 <div class="doc_subsection">
 143 <a name="clangsa">Clang Static Analyzer</a>
 144 </div>
 145
 146 <div class="doc_text">
 147
 148 <p>Previously announced in the 2.4, 2.5, and 2.6 LLVM releases, the Clang project also
 149 includes an early stage static source code analysis tool for <a
 150 href="http://clang.llvm.org/StaticAnalysis.html">automatically finding bugs</a>
 151 in C and Objective-C programs. The tool performs checks to find
 152 bugs that occur on a specific path within a program.</p>
 153
 154 <p>In the LLVM 2.7 time-frame, the analyzer core has sprouted legs and...</p>
 155
 156 </div>
 157
 158 <!--=========================================================================-->
 159 <div class="doc_subsection">
 160 <a name="vmkit">VMKit: JVM/CLI Virtual Machine Implementation</a>
 161 </div>
 162
 163 <div class="doc_text">
 164 <p>
 165 The <a href="http://vmkit.llvm.org/">VMKit project</a> is an implementation of
 166 a JVM and a CLI Virtual Machine (Microsoft .NET is an
 167 implementation of the CLI) using LLVM for static and just-in-time
 168 compilation.</p>
 169
 170 <p>
 171 With the release of LLVM 2.7, VMKit has shifted to a great framework for writing
 172 virtual machines. VMKit now offers precise and efficient garbage collection with
 173 multi-threading support, thanks to the MMTk memory management toolkit, as well
 174 as just in time and ahead of time compilation with LLVM.  The major changes in
 175 VMKit 0.27 are:</p>
 176
 177 <ul>
 178
 179 <li>Garbage collection: VMKit now uses the MMTk toolkit for garbage collectors.
 180   The first collector to be ported is the MarkSweep collector, which is precise,
 181   and drastically improves the performance of VMKit.</li>
 182 <li>Line number information in the JVM: by using the debug metadata of LLVM, the
 183  JVM now supports precise line number information, useful when printing a stack
 184  trace.</li>
 185 <li>Interface calls in the JVM: we implemented a variant of the Interface Method
 186   Table technique for interface calls in the JVM.
 187 </li>
 188
 189 </ul>
 190 </div>
 191
 192
 193 <!--=========================================================================-->
 194 <div class="doc_subsection">
 195 <a name="compiler-rt">compiler-rt: Compiler Runtime Library</a>
 196 </div>
 197
 198 <div class="doc_text">
 199 <p>
 200 The new LLVM <a href="http://compiler-rt.llvm.org/">compiler-rt project</a>
 201 is a simple library that provides an implementation of the low-level
 202 target-specific hooks required by code generation and other runtime components.
 203 For example, when compiling for a 32-bit target, converting a double to a 64-bit
 204 unsigned integer is compiled into a runtime call to the "__fixunsdfdi"
 205 function. The compiler-rt library provides highly optimized implementations of
 206 this and other low-level routines (some are 3x faster than the equivalent
 207 libgcc routines).</p>
 208
 209 <p>
 210 All of the code in the compiler-rt project is available under the standard LLVM
 211 License, a "BSD-style" license.  New in LLVM 2.7: compiler_rt now
 212 supports ARM targets.</p>
 213
 214 </div>
 215
 216 <!--=========================================================================-->
 217 <div class="doc_subsection">
 218 <a name="dragonegg">DragonEgg: llvm-gcc ported to gcc-4.5</a>
 219 </div>
 220
 221 <div class="doc_text">
 222 <p>
 223 <a href="http://dragonegg.llvm.org/">DragonEgg</a> is a port of llvm-gcc to
 224 gcc-4.5.  Unlike llvm-gcc, which makes many intrusive changes to the underlying
 225 gcc-4.2 code, dragonegg in theory does not require any gcc-4.5 modifications
 226 whatsoever (currently one small patch is needed).  This is thanks to the new
 227 <a href="http://gcc.gnu.org/wiki/plugins">gcc plugin architecture</a>, which
 228 makes it possible to modify the behaviour of gcc at runtime by loading a plugin,
 229 which is nothing more than a dynamic library which conforms to the gcc plugin
 230 interface.  DragonEgg is a gcc plugin that causes the LLVM optimizers to be run
 231 instead of the gcc optimizers, and the LLVM code generators instead of the gcc
 232 code generators, just like llvm-gcc.  To use it, you add
 233 "-fplugin=path/dragonegg.so" to the gcc-4.5 command line, and gcc-4.5 magically
 234 becomes llvm-gcc-4.5!
 235 </p>
 236
 237 <p>
 238 DragonEgg is still a work in progress.  Currently C works very well, while C++,
 239 Ada and Fortran work fairly well.  All other languages either don't work at all,
 240 or only work poorly.  For the moment only the x86-32 and x86-64 targets are
 241 supported, and only on linux and darwin (darwin needs an additional gcc patch).
 242 </p>
 243
 244 <p>
 245 DragonEgg is a new project which is seeing its first release with llvm-2.7.
 246 </p>
 247
 248 </div>
 249
 250
 251 <!--=========================================================================-->
 252 <div class="doc_subsection">
 253 <a name="mc">llvm-mc: Machine Code Toolkit</a>
 254 </div>
 255
 256 <div class="doc_text">
 257 <p>
 258 The LLVM Machine Code (MC) Toolkit project is ...
 259 </p>
 260
 261 <p>
 262 MC Disassembler (with blog post), MCInstPrinter.  Many X86 backend and AsmPrinter simplifications
 263 Can transcode from GAS to intel syntax with "llvm-mc foo.s -output-asm-variant=1"
 264 </p>
 265
 266 </div>
 267
 268
 269 <!-- *********************************************************************** -->
 270 <div class="doc_section">
 271   <a name="externalproj">External Open Source Projects Using LLVM 2.7</a>
 272 </div>
 273 <!-- *********************************************************************** -->
 274
 275 <div class="doc_text">
 276
 277 <p>An exciting aspect of LLVM is that it is used as an enabling technology for
 278    a lot of other language and tools projects.  This section lists some of the
 279    projects that have already been updated to work with LLVM 2.7.</p>
 280 </div>
 281
 282 <!--=========================================================================-->
 283 <div class="doc_subsection">
 284 <a name="pure">Pure</a>
 285 </div>
 286
 287 <div class="doc_text">
 288 <p>
 289 <a href="http://pure-lang.googlecode.com/">Pure</a>
 290 is an algebraic/functional programming language based on term rewriting.
 291 Programs are collections of equations which are used to evaluate expressions in
 292 a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation,
 293 lexical closures, a hygienic macro system (also based on term rewriting),
 294 built-in list and matrix support (including list and matrix comprehensions) and
 295 an easy-to-use C interface. The interpreter uses LLVM as a backend to
 296  JIT-compile Pure programs to fast native code.</p>
 297
 298 <p>Pure versions 0.43 and later have been tested and are known to work with
 299 LLVM 2.7 (and continue to work with older LLVM releases >= 2.5).</p>
 300
 301 </div>
 302
 303 <!--=========================================================================-->
 304 <div class="doc_subsection">
 305 <a name="RoadsendPHP">Roadsend PHP</a>
 306 </div>
 307
 308 <div class="doc_text">
 309 <p>
 310 <a href="http://code.roadsend.com/rphp">Roadsend PHP</a> (rphp) is an open
 311 source implementation of the PHP programming
 312 language that uses LLVM for its optimizer, JIT and static compiler. This is a
 313 reimplementation of an earlier project that is now based on LLVM.
 314 </p>
 315 </div>
 316
 317 <!--=========================================================================-->
 318 <div class="doc_subsection">
 319 <a name="UnladenSwallow">Unladen Swallow</a>
 320 </div>
 321
 322 <div class="doc_text">
 323 <p>
 324 <a href="http://code.google.com/p/unladen-swallow/">Unladen Swallow</a> is a
 325 branch of <a href="http://python.org/">Python</a> intended to be fully
 326 compatible and significantly faster.  It uses LLVM's optimization passes and JIT
 327 compiler.
 328 </p>
 329 </div>
 330
 331 <!--=========================================================================-->
 332 <div class="doc_subsection">
 333 <a name="tce">TTA-based Codesign Environment (TCE)</a>
 334 </div>
 335
 336 <div class="doc_text">
 337 <p>
 338 <a href="http://tce.cs.tut.fi/">TCE</a> is a toolset for designing
 339 application-specific processors (ASP) based on the Transport triggered
 340 architecture (TTA). The toolset provides a complete co-design flow from C/C++
 341 programs down to synthesizable VHDL and parallel program binaries. Processor
 342 customization points include the register files, function units, supported
 343 operations, and the interconnection network.</p>
 344
 345 <p>TCE uses llvm-gcc/Clang and LLVM for C/C++ language support, target
 346 independent optimizations and also for parts of code generation. It generates
 347 new LLVM-based code generators "on the fly" for the designed TTA processors and
 348 loads them in to the compiler backend as runtime libraries to avoid per-target
 349 recompilation of larger parts of the compiler chain.</p>
 350
 351 </div>
 352
 353 <!--=========================================================================-->
 354 <div class="doc_subsection">
 355 <a name="safecode">SAFECode Compiler</a>
 356 </div>
 357
 358 <div class="doc_text">
 359 <p>
 360 <a href="http://safecode.cs.illinois.edu">SAFECode</a> is a memory safe C
 361 compiler built using LLVM.  It takes standard, unannotated C code, analyzes the
 362 code to ensure that memory accesses and array indexing operations are safe, and
 363 instruments the code with run-time checks when safety cannot be proven
 364 statically.
 365 </p>
 366 </div>
 367
 368
 369 <!-- *********************************************************************** -->
 370 <div class="doc_section">
 371   <a name="whatsnew">What's New in LLVM 2.7?</a>
 372 </div>
 373 <!-- *********************************************************************** -->
 374
 375 <div class="doc_text">
 376
 377 <p>This release includes a huge number of bug fixes, performance tweaks and
 378 minor improvements.  Some of the major improvements and new features are listed
 379 in this section.
 380 </p>
 381
 382 </div>
 383
 384 <!--=========================================================================-->
 385 <div class="doc_subsection">
 386 <a name="orgchanges">LLVM Community Changes</a>
 387 </div>
 388
 389 <div class="doc_text">
 390
 391 <p>In addition to changes to the code, between LLVM 2.6 and 2.7, a number of
 392 organization changes have happened:
 393 </p>
 394
 395 <ul>
 396 <li>LLVM has a new <a href="http://llvm.org/Logo.html">official logo</a>!</li>
 397
 398 <li>Ted Kremenek and Doug Gregor have stepped forward as <a
 399  href="http://llvm.org/docs/DeveloperPolicy.html#owners">Code Owners</a> of the
 400  Clang static analyzer and the Clang frontend, respectively.</li>
 401
 402 <li>LLVM now has an <a href="http://blog.llvm.org">official Blog</a> at
 403     <a href="http://blog.llvm.org">http://blog.llvm.org</a>. This is a great way
 404     to learn about new LLVM-related features as they are implemented.  Several
 405     features in this release are already explained on the blog.</li>
 406
 407 <li>The LLVM web pages are now checked into the SVN server, in the "www",
 408     "www-pubs" and "www-releases" SVN modules.  Previously they were hidden in a
 409     largely inaccessible old CVS server.</li>
 410
 411 <li><a href="http://llvm.org">llvm.org</a> is now hosted on a new (and much
 412     faster) server.  It is still graciously hosted at the University of Illinois
 413     of Urbana Champaign.</li>
 414 </ul>
 415 </div>
 416
 417 <!--=========================================================================-->
 418 <div class="doc_subsection">
 419 <a name="majorfeatures">Major New Features</a>
 420 </div>
 421
 422 <div class="doc_text">
 423
 424 <p>LLVM 2.7 includes several major new capabilities:</p>
 425
 426 <ul>
 427 <li>2.7 includes initial support for the <a
 428   href="http://en.wikipedia.org/wiki/MicroBlaze">MicroBlaze</a> target.
 429   MicroBlaze is a soft processor core designed for Xilinx FPGAs.</li>
 430
 431 <li>2.7 includes a new LLVM IR "extensible metadata" feature.  This feature
 432  supports many different use cases, including allowing front-end authors to
 433  encode source level information into LLVM IR, which is consumed by later
 434  language-specific passes.  This is a great way to do high-level optimizations
 435  like devirtualization, type-based alias analysis, etc.  See the <a
 436  href="http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html">
 437  Extensible Metadata Blog Post</a> for more information.</li>
 438
 439 <li>2.7 encodes <a href="SourceLevelDebugging.html">debug information</a>
 440 in a completely new way, built on extensible metadata.  The new implementation
 441 is much more memory efficient and paves the way for improvements to optimized
 442 code debugging experience.</li>
 443
 444 <li>2.7 now directly supports taking the address of a label and doing an
 445     indirect branch through a pointer.  This is particularly useful for
 446     interpreter loops, and is used to implement the GCC "address of label"
 447     extension.  For more information, see the <a
 448 href="http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html">
 449 Address of Label and Indirect Branches in LLVM IR Blog Post</a>.
 450
 451 <li>2.7 is the first release to start supporting APIs for assembling and
 452     disassembling target machine code.  These APIs are useful for a variety of
 453     low level clients, and are surfaced in the new "enhanced disassembly" API.
 454     For more information see the <a
 455     href="http://blog.llvm.org/2010/01/x86-disassembler.html">The X86
 456     Disassembler Blog Post</a> for more information.</li>
 457
 458 <li>2.7 includes major parts of the work required by the new MC Project,
 459     which aims to rework our handling of low-level machine code.  A few targets
 460     have been refactored to support it, and work is underway to support a native
 461     assembler in LLVM.  This work is not complete in LLVM 2.7, but you has made
 462     substantially more progress on LLVM mainline.  You can read more about this
 463     in the <a href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">
 464     Intro to the LLVM MC Project Blog Post</a>.
 465 </li>
 466
 467 </ul>
 468
 469 </div>
 470
 471 <!--=========================================================================-->
 472 <div class="doc_subsection">
 473 <a name="coreimprovements">LLVM IR and Core Improvements</a>
 474 </div>
 475
 476 <div class="doc_text">
 477 <p>LLVM IR has several new features for better support of new targets and that
 478 expose new optimization opportunities:</p>
 479
 480 <ul>
 481 <li>LLVM IR now supports a 16-bit "half float" data type through <a
 482    href="LangRef.html#int_fp16">two new intrinsics</a> and APFloat support.</li>
 483 <li>LLVM IR supports two new <a href="LangRef.html#fnattrs">function
 484     attributes</a>: inlinehint and alignstack(n).  The former is a hint to the
 485     optimizer that a function was declared 'inline' and thus the inliner should
 486     weight it higher when considering inlining it.  The later
 487     indicates to the code generator that the function diverges from the platform
 488     ABI on stack alignment.</li>
 489 <li>The new <a href="LangRef.html#int_objectsize">llvm.objectsize</a> intrinsic
 490     allows the optimizer to infer the sizes of memory objects in some cases.
 491     This intrinsic is used to implement the GCC <tt>__builtin_object_size</tt>
 492     extension.</li>
 493 <li>LLVM IR now supports marking load and store instructions with <a
 494     href="LangRef.html#i_load">"non-temporal" hints</a> (building on the new
 495     metadata feature).  This hint encourages the code
 496     generator to generate non-temporal accesses when possible, which are useful
 497     for code that is carefully managing cache behavior.  Currently, only the
 498     X86 backend provides target support for this feature.</li>
 499
 500 <li>LLVM 2.7 has pre-alpha support for <a
 501   href="http://llvm.org/docs/LangRef.html#t_union">unions in LLVM IR</a>.
 502   Unfortunately, this support is not really usable in 2.7, so if you're
 503  interested in pushing it forward, please help contribute to LLVM mainline.</li>
 504 </li>
 505 </ul>
 506
 507 </div>
 508
 509 <!--=========================================================================-->
 510 <div class="doc_subsection">
 511 <a name="optimizer">Optimizer Improvements</a>
 512 </div>
 513
 514 <div class="doc_text">
 515
 516 <p>In addition to a large array of minor performance tweaks and bug fixes, this
 517 release includes a few major enhancements and additions to the optimizers:</p>
 518
 519 <ul>
 520
 521 <li>The inliner reuses now merges arrays stack objects in different callees when
 522     inlining multiple call sites into one function.  This reduces the stack size
 523     of the resultant function.</li>
 524 <li>The -basicaa alias analysis pass (which is the default) has been improved to
 525     be less dependent on "type safe" pointers.  It can now look through bitcasts
 526     and other constructs more aggressively, allowing better load/store
 527     optimization.</li>
 528 <li>The load elimination optimization in the GVN Pass [<a
 529 href="http://blog.llvm.org/2009/12/introduction-to-load-elimination-in-gvn.html">intro
 530  blog post</a>] has been substantially improved to be more aggressive about
 531  partial redundancy elimination and do more aggressive phi translation.  Please
 532  see the <a
 533  href="http://blog.llvm.org/2009/12/advanced-topics-in-redundant-load.html">
 534  Advanced Topics in Redundant Load Elimination with a Focus on PHI Translation
 535  Blog Post</a> for more details.</li>
 536 <li>The module <a href="LangRef.html#datalayout">target data string</a> now
 537     includes a notion of what the 'native' integer data types a for the target,
 538     which allows various optimizations to use.  This helps mid-level
 539     optimizations avoid promoting complex sequences of operations to data types
 540     that are not natively supported (e.g. converting i32 operations to i64 on
 541     a 32-bit chip).</li>
 542 <li>The mid-level optimizer is now conservative when operating on a module with
 543     no target data.  Previously, it would default to SparcV9 settings, which is
 544     not what most people expected.</li>
 545 <li>Jump threading is now much more aggressive at simplifying correlated
 546    conditionals and threading blocks with otherwise complex logic. It has
 547    subsumed the old "Conditional Propagation" pass, and -condprop has been
 548    removed from LLVM 2.7.</li>
 549 <li>The -instcombine pass has been refactored from being one huge file to being
 550     a library of its own.  Internally, it uses a customized IRBuilder to clean
 551     it up and simplify it.</li>
 552
 553 <li>The optimal edge profiling pass is reliable and much more complete than in
 554     2.6.  It can be used with the llvm-prof tool but isn't wired up to the
 555     llvm-gcc and clang command line options yet.</li>
 556
 557 <li>A new experimental alias analysis implementation, -scev-aa, has been added.
 558     It uses LLVM's Scalar Evolution implementation to do symbolic analysis of
 559     pointer offset expressions to disambiguate pointers.  It can catch a few
 560     cases that basicaa cannot, particularly in complex loop nests.</li>
 561
 562 <li>The default pass ordering has been tweaked for improved optimization
 563     effectiveness.</li>
 564
 565 </ul>
 566
 567 </div>
 568
 569
 570 <!--=========================================================================-->
 571 <div class="doc_subsection">
 572 <a name="executionengine">Interpreter and JIT Improvements</a>
 573 </div>
 574
 575 <div class="doc_text">
 576
 577 <ul>
 578 <li>The JIT now supports generating debug information, which is compatible with
 579 the new GDB 7.0 (and later) interfaces for registering debug info for
 580 dynamically generated code.</li>
 581
 582 <li>The JIT now <a href="http://llvm.org/PR5184">defaults
 583 to compiling eagerly</a> to avoid a race condition in the lazy JIT.
 584 Clients that still want the lazy JIT can switch it on by calling
 585 <tt>ExecutionEngine::DisableLazyCompilation(false)</tt>.</li>
 586
 587 <li>It is now possible to create more than one JIT instance in the same process.
 588 These JITs can generate machine code in parallel,
 589 although <a href="http://llvm.org/docs/ProgrammersManual.html#jitthreading">you
 590 still have to obey the other threading restrictions</a>.</li>
 591
 592 </ul>
 593
 594 </div>
 595
 596 <!--=========================================================================-->
 597 <div class="doc_subsection">
 598 <a name="codegen">Target Independent Code Generator Improvements</a>
 599 </div>
 600
 601 <div class="doc_text">
 602
 603 <p>We have put a significant amount of work into the code generator
 604 infrastructure, which allows us to implement more aggressive algorithms and make
 605 it run faster:</p>
 606
 607 <ul>
 608 <li>The 'llc -asm-verbose' option (which is now the default) has been enhanced
 609     to emit many useful comments to .s files indicating information about spill
 610     slots and loop nest structure.  This should make it much easier to read and
 611     understand assembly files.  This is wired up in llvm-gcc and clang to
 612     the <tt>-fverbose-asm</tt> option.</li>
 613
 614 <li>New LSR with "full strength reduction" mode.  FIXME: Description?</li>
 615
 616 <li>A new codegen level Common Subexpression Elimination pass (MachineCSE)
 617     is available and enabled by default.  It catches redundancies exposed by
 618     lowering.</li>
 619 <li>A new pre-register-allocation tail duplication pass is available and enabled
 620     by default, it can substantially improve branch prediction quality in some
 621     cases.</li>
 622 <li>A new sign and zero extension optimization pass (OptimizeExtsPass)
 623     is available and enabled by default.  This pass can takes advantage
 624     architecture features like x86-64 implicit zero extension behavior and
 625     sub-registers.</li>
 626 <li>The code generator now supports a mode where it attempts to preserve the
 627     order of instructions in the input code.  This is important for source that
 628     is hand scheduled and extremely sensitive to scheduling.  It is compatible
 629     with the GCC <tt>-fno-schedule-insns</tt> option.</li>
 630 <li>The target-independent code generator now supports generating code with
 631     arbitrary numbers of result values.  Returning more values than was
 632     previously supported is handled by returning through a hidden pointer.  In
 633     2.7, only the X86 and XCore targets have adopted support for this
 634     though.</li>
 635 <li>The code generator now supports generating code that follows the
 636     <a href="LangRef.html#callingconv">Glasgow Haskell Compiler Calling
 637     Convention</a> and ABI.</li>
 638 <li>The "<a href="CodeGenerator.html#selectiondag_select">DAG instruction
 639     selection</a>" phase of the code generator has been largely rewritten for
 640     2.7.  Previously, tblgen spit out tons of C++ code which was compiled and
 641     linked into the target to do the pattern matching, now it emits a much
 642     smaller table which is read by the target-independent code.  The primary
 643     advantages of this approach is that the size and compile time of various
 644     targets is much improved.  The X86 code generator shrunk by 1.5MB of code,
 645     for example.</li>
 646 <li>Almost the entire code generator has switched to emitting code through the
 647     MC interfaces instead of printing textually to the .s file.  This led to a
 648     number of cleanups and speedups.  In 2.7, debug an exception handling
 649     information does not go through MC yet.</li>
 650 </ul>
 651 </div>
 652
 653 <!--=========================================================================-->
 654 <div class="doc_subsection">
 655 <a name="x86">X86-32 and X86-64 Target Improvements</a>
 656 </div>
 657
 658 <div class="doc_text">
 659 <p>New features of the X86 target include:
 660 </p>
 661
 662 <ul>
 663 <li>The X86 backend now optimizes tails calls much more aggressively for
 664     functions that use the standard C calling convention.</li>
 665 <li>The X86 backend now models scalar SSE registers as subregs of the SSE vector
 666     registers, making the code generator more aggressive in cases where scalars
 667     and vector types are mixed.</li>
 668
 669 <li>PostRA scheduler for X86? FIXME: is this on by default in 2.7?</li>
 670
 671 </ul>
 672
 673 </div>
 674
 675 <!--=========================================================================-->
 676 <div class="doc_subsection">
 677 <a name="ARM">ARM Target Improvements</a>
 678 </div>
 679
 680 <div class="doc_text">
 681 <p>New features of the ARM target include:
 682 </p>
 683
 684 <ul>
 685
 686 <li>The ARM backend now generates instructions in unified assembly syntax.</li>
 687
 688 <li>llvm-gcc now has complete support for the ARM v7 NEON instruction set.  This
 689    support differs slightly from the GCC implementation.  Please see the
 690    <a
 691 href="http://blog.llvm.org/2010/04/arm-advanced-simd-neon-intrinsics-and.html">
 692   ARM Advanced SIMD (NEON) Intrinsics and Types in LLVM Blog Post</a> for
 693   helpful information if migrating code from GCC to LLVM-GCC.</li>
 694
 695 <li>The ARM and Thumb code generators now using register scavenging for stack
 696     object address materialization.(FIXME: WHAT BENEFIT DOES THIS PROVIDE?)</li>
 697
 698 <li>The ARM backend now has good support for ARMv4 targets, and has been tested
 699     on StrongARM hardware.  Previously, LLVM only supported ARMv4T and
 700     newer chips.</li>
 701 </ul>
 702
 703
 704 </div>
 705
 706 <!--=========================================================================-->
 707 <div class="doc_subsection">
 708 <a name="newapis">New Useful APIs</a>
 709 </div>
 710
 711 <div class="doc_text">
 712
 713 <p>This release includes a number of new APIs that are used internally, which
 714    may also be useful for external clients.
 715 </p>
 716
 717 <ul>
 718 <li>The optimizer uses the new CodeMetrics class to measure the size of code.
 719     Various passes that use thing (like the inliner, loop unswitcher, etc) all
 720     use this to make more accurate estimates of the code size impact of various
 721     optimizations.</li>
 722 <li>A new <a href="http://llvm.org/doxygen/InstructionSimplify_8h-source.html">
 723     llvm/Analysis/InstructionSimplify.h</a> interface available for doing
 724     symbolic simplification of instructions (e.g. <tt>a+0</tt> -&gt; <tt>a</tt>)
 725     without requiring the instruction to exist.  This centralizes a lot of
 726     ad-hoc symbolic manipulation code scattered in various passes.</li>
 727 <li>The optimizer now uses a new <a
 728     href="http://llvm.org/doxygen/SSAUpdater_8h-source.html">SSAUpdater</a>
 729     class which efficiently supports
 730     doing unstructured SSA update operations.  This centralized a bunch of code
 731     scattered through various passes (e.g. jump threading, lcssa, loop rotate,
 732     etc) for doing this sort of thing.  The code generator has an similar
 733     <a href="http://llvm.org/doxygen/MachineSSAUpdater_8h-source.html">
 734     MachineSSAUpdater</a> class.</li>
 735 <li>The <a href="http://llvm.org/doxygen/Regex_8h-source.html">
 736     llvm/Support/Regex.h</a> header exposes a platform independent regular
 737     expression API.  Building on this, the <a
 738     href="TestingGuide.html#FileCheck">FileCheck</a> utility now supports
 739     regular exressions.</li>
 740 <li>raw_ostream now supports a circular "debug stream" accessed with "dbgs()".
 741     By default, this stream works the same way as "errs()", but if you pass
 742     <tt>-debug-buffer-size=1000</tt> to opt, the debug stream is capped to a
 743     fixed sized circular buffer and the output is printed at the end of the
 744     program's execution.  This is helpful if you have a long lived compiler
 745     process and you're interested in seeing snapshots in time.</li>
 746 </ul>
 747
 748
 749 </div>
 750
 751 <!--=========================================================================-->
 752 <div class="doc_subsection">
 753 <a name="otherimprovements">Other Improvements and New Features</a>
 754 </div>
 755
 756 <div class="doc_text">
 757 <p>Other miscellaneous features include:</p>
 758
 759 <ul>
 760 <li>You can now build LLVM as a big dynamic library (e.g. "libllvm2.7.so"). To
 761     get this, configure LLVM with the --enable-shared option.</li>
 762
 763 <li>LLVM command line tools now overwrite their output by default, before they
 764     would only do this with -f. This makes them more convenient to use, and
 765     behave more like standard unix tools.</li>
 766
 767 <li>The opt and llc tools now autodetect whether their input is a .ll or .bc
 768     file, and automatically do the right thing.  This means you don't need to
 769     explicitly use the llvm-as tool for most things.</li>
 770 </ul>
 771
 772 </div>
 773
 774
 775 <!--=========================================================================-->
 776 <div class="doc_subsection">
 777 <a name="changes">Major Changes and Removed Features</a>
 778 </div>
 779
 780 <div class="doc_text">
 781
 782 <p>If you're already an LLVM user or developer with out-of-tree changes based
 783 on LLVM 2.6, this section lists some "gotchas" that you may run into upgrading
 784 from the previous release.</p>
 785
 786 <ul>
 787
 788 <li>
 789 The Andersen's alias analysis ("anders-aa") pass, the Predicate Simplifier
 790 ("predsimplify") pass, the LoopVR pass, the GVNPRE pass, and the random sampling
 791 profiling ("rsprofiling") passes have all been removed.  They were not being
 792 actively maintained and had substantial problems.  If you are interested in
 793 these components, you are welcome to ressurect them from SVN, fix the
 794 correctness problems, and resubmit them to mainline.</li>
 795
 796 <li>LLVM now defaults to building most libraries with RTTI turned off, providing
 797 a code size reduction.  Packagers who are interested in building LLVM to support
 798 plugins that require RTTI information should build with "make REQUIRE_RTTI=1"
 799 and should read the new <a href="Packaging.html">Advice on Packaging LLVM</a>
 800 document.</li>
 801
 802 <li>The LLVM interpreter now defaults to <em>not</em> using <tt>libffi</tt> even
 803 if you have it installed.  This makes it more likely that an LLVM built on one
 804 system will work when copied to a similar system.  To use <tt>libffi</tt>,
 805 configure with <tt>--enable-libffi</tt>.</li>
 806
 807 <li>Debug information uses a completely different representation, an LLVM 2.6
 808 .bc file should work with LLVM 2.7, but debug info won't come forward.</li>
 809
 810 <li>The LLVM 2.6 (and earlier) "malloc" and "free" instructions got removed,
 811     along with LowerAllocations pass.  Now you should just use a call to the
 812     malloc and free functions in libc.  These calls are optimized as well as
 813     the old instructions were.</li>
 814 </ul>
 815
 816 <p>In addition, many APIs have changed in this release.  Some of the major LLVM
 817 API changes are:</p>
 818
 819 <ul>
 820 <li>Just about everything has been converted to use raw_ostream instead of
 821     std::ostream.</li>
 822 <li>llvm/ADT/iterator.h has been removed, just use &lt;iterator&gt;
 823  instead.</li>
 824 <li>The Streams.h file and "DOUT" got removed, use "DEBUG(errs() &lt;&lt; ...);"
 825    instead.</li>
 826 <li><tt>ModuleProvider</tt> has been <a
 827 href="http://llvm.org/viewvc/llvm-project?view=rev&revision=94686">removed</a>
 828 and its methods moved to <tt>Module</tt> and <tt>GlobalValue</tt>.
 829 Most clients can remove uses of <tt>ExistingModuleProvider</tt>,
 830 replace <tt>getBitcodeModuleProvider</tt> with
 831 <tt>getLazyBitcodeModule</tt>, and pass their <tt>Module</tt> to
 832 functions that used to accept <tt>ModuleProvider</tt>.  Clients who
 833 wrote their own <tt>ModuleProvider</tt>s will need to derive from
 834 <tt>GVMaterializer</tt> instead and use
 835 <tt>Module::setMaterializer</tt> to attach it to a
 836 <tt>Module</tt>.</li>
 837
 838 <li><tt>GhostLinkage</tt> has given up the ghost.
 839 <tt>GlobalValue</tt>s that have not yet been read from their backing
 840 storage have the same linkage they will have after being read in.
 841 Clients must replace calls to
 842 <tt>GlobalValue::hasNotBeenReadFromBitcode</tt> with
 843 <tt>GlobalValue::isMaterializable</tt>.</li>
 844
 845 <li>The <tt>llvm/Support/DataTypes.h</tt> header has moved
 846 to <tt>llvm/System/DataTypes.h</tt>.</li>
 847
 848 <li>The <tt>isInteger</tt>, <tt>isIntOrIntVector</tt>, <tt>isFloatingPoint</tt>,
 849 <tt>isFPOrFPVector</tt> and <tt>isFPOrFPVector</tt> methods have been renamed
 850 <tt>isIntegerTy</tt>, <tt>isIntOrIntVectorTy</tt>, <tt>isFloatingPointTy</tt>,
 851 <tt>isFPOrFPVectorTy</tt> and <tt>isFPOrFPVectorTy</tt> respectively.</li>
 852 </ul>
 853
 854 </div>
 855
 856
 857
 858 <!-- *********************************************************************** -->
 859 <div class="doc_section">
 860   <a name="portability">Portability and Supported Platforms</a>
 861 </div>
 862 <!-- *********************************************************************** -->
 863
 864 <div class="doc_text">
 865
 866 <p>LLVM is known to work on the following platforms:</p>
 867
 868 <ul>
 869 <li>Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat
 870     Linux, Fedora Core, FreeBSD and AuroraUX (and probably other unix-like
 871     systems).</li>
 872 <li>PowerPC and X86-based Mac OS X systems, running 10.4 and above in 32-bit
 873     and 64-bit modes.</li>
 874 <li>Intel and AMD machines running on Win32 using MinGW libraries (native).</li>
 875 <li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
 876     support is available for native builds with Visual C++).</li>
 877 <li>Sun x86 and AMD64 machines running Solaris 10, OpenSolaris 0906.</li>
 878 <li>Alpha-based machines running Debian GNU/Linux.</li>
 879 </ul>
 880
 881 <p>The core LLVM infrastructure uses GNU autoconf to adapt itself
 882 to the machine and operating system on which it is built.  However, minor
 883 porting may be required to get LLVM to work on new platforms.  We welcome your
 884 portability patches and reports of successful builds or error messages.</p>
 885
 886 </div>
 887
 888 <!-- *********************************************************************** -->
 889 <div class="doc_section">
 890   <a name="knownproblems">Known Problems</a>
 891 </div>
 892 <!-- *********************************************************************** -->
 893
 894 <div class="doc_text">
 895
 896 <p>This section contains significant known problems with the LLVM system,
 897 listed by component.  If you run into a problem, please check the <a
 898 href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
 899 there isn't already one.</p>
 900
 901 <ul>
 902 <li>LLVM will not correctly compile on Solaris and/or OpenSolaris
 903 using the stock GCC 3.x.x series 'out the box',
 904 See: <a href="GettingStarted.html#brokengcc">Broken versions of GCC and other tools</a>.
 905 However, A <a href="http://pkg.auroraux.org/GCC">Modern GCC Build</a>
 906 for x86/x86-64 has been made available from the third party AuroraUX Project
 907 that has been meticulously tested for bootstrapping LLVM &amp; Clang.</li>
 908 </ul>
 909
 910 </div>
 911
 912 <!-- ======================================================================= -->
 913 <div class="doc_subsection">
 914   <a name="experimental">Experimental features included with this release</a>
 915 </div>
 916
 917 <div class="doc_text">
 918
 919 <p>The following components of this LLVM release are either untested, known to
 920 be broken or unreliable, or are in early development.  These components should
 921 not be relied on, and bugs should not be filed against them, but they may be
 922 useful to some people.  In particular, if you would like to work on one of these
 923 components, please contact us on the <a
 924 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
 925
 926 <ul>
 927 <li>The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430, SystemZ and MicroBlaze
 928     backends are experimental.</li>
 929 <li><tt>llc</tt> "<tt>-filetype=asm</tt>" (the default) is the only
 930     supported value for this option.  The MachO writer is experimental, and
 931     works much better in mainline SVN.</li>
 932 </ul>
 933
 934 </div>
 935
 936 <!-- ======================================================================= -->
 937 <div class="doc_subsection">
 938   <a name="x86-be">Known problems with the X86 back-end</a>
 939 </div>
 940
 941 <div class="doc_text">
 942
 943 <ul>
 944   <li>The X86 backend does not yet support
 945     all <a href="http://llvm.org/PR879">inline assembly that uses the X86
 946     floating point stack</a>.  It supports the 'f' and 't' constraints, but not
 947     'u'.</li>
 948   <li>The X86 backend generates inefficient floating point code when configured
 949     to generate code for systems that don't have SSE2.</li>
 950   <li>Win64 code generation wasn't widely tested. Everything should work, but we
 951     expect small issues to happen. Also, llvm-gcc cannot build the mingw64
 952     runtime currently due to lack of support for the 'u' inline assembly
 953     constraint and for X87 floating point inline assembly.</li>
 954   <li>The X86-64 backend does not yet support the LLVM IR instruction
 955       <tt>va_arg</tt>. Currently, front-ends support variadic
 956       argument constructs on X86-64 by lowering them manually.</li>
 957 </ul>
 958
 959 </div>
 960
 961 <!-- ======================================================================= -->
 962 <div class="doc_subsection">
 963   <a name="ppc-be">Known problems with the PowerPC back-end</a>
 964 </div>
 965
 966 <div class="doc_text">
 967
 968 <ul>
 969 <li>The Linux PPC32/ABI support needs testing for the interpreter and static
 970 compilation, and lacks support for debug information.</li>
 971 </ul>
 972
 973 </div>
 974
 975 <!-- ======================================================================= -->
 976 <div class="doc_subsection">
 977   <a name="arm-be">Known problems with the ARM back-end</a>
 978 </div>
 979
 980 <div class="doc_text">
 981
 982 <ul>
 983 <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
 984 processors, thumb programs can crash or produce wrong
 985 results (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
 986 <li>Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
 987 </li>
 988 </ul>
 989
 990 </div>
 991
 992 <!-- ======================================================================= -->
 993 <div class="doc_subsection">
 994   <a name="sparc-be">Known problems with the SPARC back-end</a>
 995 </div>
 996
 997 <div class="doc_text">
 998
 999 <ul>
1000 <li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
1001     support the 64-bit SPARC ABI (-m64).</li>
1002 </ul>
1003
1004 </div>
1005
1006 <!-- ======================================================================= -->
1007 <div class="doc_subsection">
1008   <a name="mips-be">Known problems with the MIPS back-end</a>
1009 </div>
1010
1011 <div class="doc_text">
1012
1013 <ul>
1014 <li>64-bit MIPS targets are not supported yet.</li>
1015 </ul>
1016
1017 </div>
1018
1019 <!-- ======================================================================= -->
1020 <div class="doc_subsection">
1021   <a name="alpha-be">Known problems with the Alpha back-end</a>
1022 </div>
1023
1024 <div class="doc_text">
1025
1026 <ul>
1027
1028 <li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
1029 appropriate nops inserted to ensure restartability.</li>
1030
1031 </ul>
1032 </div>
1033
1034 <!-- ======================================================================= -->
1035 <div class="doc_subsection">
1036   <a name="c-be">Known problems with the C back-end</a>
1037 </div>
1038
1039 <div class="doc_text">
1040
1041 <ul>
1042 <li><a href="http://llvm.org/PR802">The C backend has only basic support for
1043     inline assembly code</a>.</li>
1044 <li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
1045     C++ programs</a>, preventing intermixing between C++ compiled by the CBE and
1046     C++ code compiled with <tt>llc</tt> or native compilers.</li>
1047 <li>The C backend does not support all exception handling constructs.</li>
1048 <li>The C backend does not support arbitrary precision integers.</li>
1049 </ul>
1050
1051 </div>
1052
1053
1054 <!-- ======================================================================= -->
1055 <div class="doc_subsection">
1056   <a name="c-fe">Known problems with the llvm-gcc C and C++ front-end</a>
1057 </div>
1058
1059 <div class="doc_text">
1060
1061 <p>The only major language feature of GCC not supported by llvm-gcc is
1062     the <tt>__builtin_apply</tt> family of builtins.   However, some extensions
1063     are only supported on some targets.  For example, trampolines are only
1064     supported on some targets (these are used when you take the address of a
1065     nested function).</p>
1066
1067 </div>
1068
1069 <!-- ======================================================================= -->
1070 <div class="doc_subsection">
1071   <a name="fortran-fe">Known problems with the llvm-gcc Fortran front-end</a>
1072 </div>
1073
1074 <div class="doc_text">
1075 <ul>
1076 <li>Fortran support generally works, but there are still several unresolved bugs
1077     in <a href="http://llvm.org/bugs/">Bugzilla</a>.  Please see the
1078     tools/gfortran component for details.</li>
1079 </ul>
1080 </div>
1081
1082 <!-- ======================================================================= -->
1083 <div class="doc_subsection">
1084   <a name="ada-fe">Known problems with the llvm-gcc Ada front-end</a>
1085 </div>
1086
1087 <div class="doc_text">
1088 The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature
1089 technology, and problems should be expected.
1090 <ul>
1091 <li>The Ada front-end currently only builds on X86-32.  This is mainly due
1092 to lack of trampoline support (pointers to nested functions) on other platforms.
1093 However, it <a href="http://llvm.org/PR2006">also fails to build on X86-64</a>
1094 which does support trampolines.</li>
1095 <li>The Ada front-end <a href="http://llvm.org/PR2007">fails to bootstrap</a>.
1096 This is due to lack of LLVM support for <tt>setjmp</tt>/<tt>longjmp</tt> style
1097 exception handling, which is used internally by the compiler.
1098 Workaround: configure with <tt>--disable-bootstrap</tt>.</li>
1099 <li>The c380004, <a href="http://llvm.org/PR2010">c393010</a>
1100 and <a href="http://llvm.org/PR2421">cxg2021</a> ACATS tests fail
1101 (c380004 also fails with gcc-4.2 mainline).
1102 If the compiler is built with checks disabled then <a href="http://llvm.org/PR2010">c393010</a>
1103 causes the compiler to go into an infinite loop, using up all system memory.</li>
1104 <li>Some GCC specific Ada tests continue to crash the compiler.</li>
1105 <li>The <tt>-E</tt> binder option (exception backtraces)
1106 <a href="http://llvm.org/PR1982">does not work</a> and will result in programs
1107 crashing if an exception is raised.  Workaround: do not use <tt>-E</tt>.</li>
1108 <li>Only discrete types <a href="http://llvm.org/PR1981">are allowed to start
1109 or finish at a non-byte offset</a> in a record.  Workaround: do not pack records
1110 or use representation clauses that result in a field of a non-discrete type
1111 starting or finishing in the middle of a byte.</li>
1112 <li>The <tt>lli</tt> interpreter <a href="http://llvm.org/PR2009">considers
1113 'main' as generated by the Ada binder to be invalid</a>.
1114 Workaround: hand edit the file to use pointers for <tt>argv</tt> and
1115 <tt>envp</tt> rather than integers.</li>
1116 <li>The <tt>-fstack-check</tt> option <a href="http://llvm.org/PR2008">is
1117 ignored</a>.</li>
1118 </ul>
1119 </div>
1120
1121 <!-- *********************************************************************** -->
1122 <div class="doc_section">
1123   <a name="additionalinfo">Additional Information</a>
1124 </div>
1125 <!-- *********************************************************************** -->
1126
1127 <div class="doc_text">
1128
1129 <p>A wide variety of additional information is available on the <a
1130 href="http://llvm.org">LLVM web page</a>, in particular in the <a
1131 href="http://llvm.org/docs/">documentation</a> section.  The web page also
1132 contains versions of the API documentation which is up-to-date with the
1133 Subversion version of the source code.
1134 You can access versions of these documents specific to this release by going
1135 into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
1136
1137 <p>If you have any questions or comments about LLVM, please feel free to contact
1138 us via the <a href="http://llvm.org/docs/#maillist"> mailing
1139 lists</a>.</p>
1140
1141 </div>
1142
1143 <!-- *********************************************************************** -->
1144
1145 <hr>
1146 <address>
1147   <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
1148   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
1149   <a href="http://validator.w3.org/check/referer"><img
1150   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
1151
1152   <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
1153   Last modified: $Date$
1154 </address>
1155
1156 </body>
1157 </html>