<p>In the LLVM 2.7 time-frame, the Clang team has made many improvements:</p>
<ul>
-<li>...</li>
-include a link to cxx_compatibility.html
+<li>FIXME: C++! Include a link to cxx_compatibility.html</li>
+
+<li>FIXME: Static Analyzer improvements?</li>
+
+<li>CIndex API and Python bindings: Clang now includes a C API as part of the
+CIndex library. Although we make make some changes to the API in the future, it
+is intended to be stable and has been designed for use by external projects. See
+the Clang
+doxygen <a href="http://clang.llvm.org/doxygen/group__CINDEX.html">CIndex</a>
+documentation for more details. The CIndex API also includings an preliminary
+set of Python bindings.</li>
+
+<li>ARM Support: Clang now has ABI support for both the Darwin and Linux ARM
+ABIs. Coupled with many improvements to the LLVM ARM backend, Clang is now
+suitable for use as a a beta quality ARM compiler.</li>
</ul>
</div>
compilation.</p>
<p>
-VMKit version ?? builds with LLVM 2.7 and you can find it on its
-<a href="http://vmkit.llvm.org/releases/">web page</a>. The release includes
-bug fixes, cleanup and new features. The major changes are:</p>
+With the release of LLVM 2.7, VMKit has shifted to a great framework for writing
+virtual machines. VMKit now offers precise and efficient garbage collection with
+multi-threading support, thanks to the MMTk memory management toolkit, as well
+as just in time and ahead of time compilation with LLVM. The major changes in
+VMKit 0.27 are:</p>
<ul>
-<li>...</li>
+<li>Garbage collection: VMKit now uses the MMTk toolkit for garbage collectors.
+ The first collector to be ported is the MarkSweep collector, which is precise,
+ and drastically improves the performance of VMKit.</li>
+<li>Line number information in the JVM: by using the debug metadata of LLVM, the
+ JVM now supports precise line number information, useful when printing a stack
+ trace.</li>
+<li>Interface calls in the JVM: we implemented a variant of the Interface Method
+ Table technique for interface calls in the JVM.
+</li>
</ul>
</div>
<!--=========================================================================-->
<div class="doc_subsection">
-<a name="klee">KLEE: Symbolic Execution and Automatic Test Case Generator</a>
+<a name="dragonegg">DragonEgg: llvm-gcc ported to gcc-4.5</a>
</div>
<div class="doc_text">
<p>
-The new LLVM <a href="http://klee.llvm.org/">KLEE project</a> is a symbolic
-execution framework for programs in LLVM bitcode form. KLEE tries to
-symbolically evaluate "all" paths through the application and records state
-transitions that lead to fault states. This allows it to construct testcases
-that lead to faults and can even be used to verify algorithms. For more
-details, please see the <a
-href="http://llvm.org/pubs/2008-12-OSDI-KLEE.html">OSDI 2008 paper</a> about
-KLEE.</p>
-
-</div>
+<a href="http://dragonegg.llvm.org/">DragonEgg</a> is a port of llvm-gcc to
+gcc-4.5. Unlike llvm-gcc, which makes many intrusive changes to the underlying
+gcc-4.2 code, dragonegg in theory does not require any gcc-4.5 modifications
+whatsoever (currently one small patch is needed). This is thanks to the new
+<a href="http://gcc.gnu.org/wiki/plugins">gcc plugin architecture</a>, which
+makes it possible to modify the behaviour of gcc at runtime by loading a plugin,
+which is nothing more than a dynamic library which conforms to the gcc plugin
+interface. DragonEgg is a gcc plugin that causes the LLVM optimizers to be run
+instead of the gcc optimizers, and the LLVM code generators instead of the gcc
+code generators, just like llvm-gcc. To use it, you add
+"-fplugin=path/dragonegg.so" to the gcc-4.5 command line, and gcc-4.5 magically
+becomes llvm-gcc-4.5!
+</p>
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="dragonegg">DragonEgg: GCC-4.5 as an LLVM frontend</a>
-</div>
+<p>
+DragonEgg is still a work in progress. Currently C works very well, while C++,
+Ada and Fortran work fairly well. All other languages either don't work at all,
+or only work poorly. For the moment only the x86-32 and x86-64 targets are
+supported, and only on linux.
+</p>
-<div class="doc_text">
<p>
-The goal of <a href="http://dragonegg.llvm.org/">DragonEgg</a> is to make
-gcc-4.5 act like llvm-gcc without requiring any gcc modifications whatsoever.
-<a href="http://dragonegg.llvm.org/">DragonEgg</a> is a shared library (dragonegg.so)
-that is loaded by gcc at runtime. It ...
+DragonEgg has not yet been released. Once gcc-4.5 has been released, dragonegg
+will probably be released as part of the following LLVM release.
</p>
</div>
</div>
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="tce">TTA-based Codesign Environment (TCE)</a>
+</div>
+
+<div class="doc_text">
+<p>
+<a href="http://tce.cs.tut.fi/">TCE</a> is a toolset for designing
+application-specific processors (ASP) based on the Transport triggered
+architecture (TTA). The toolset provides a complete co-design flow from C/C++
+programs down to synthesizable VHDL and parallel program binaries. Processor
+customization points include the register files, function units, supported
+operations, and the interconnection network.</p>
+
+<p>TCE uses llvm-gcc/Clang and LLVM for C/C++ language support, target
+independent optimizations and also for parts of code generation. It generates
+new LLVM-based code generators "on the fly" for the designed TTA processors and
+loads them in to the compiler backend as runtime libraries to avoid per-target
+recompilation of larger parts of the compiler chain.</p>
+
+</div>
+
+<!--=========================================================================-->
+<div class="doc_subsection">
+<a name="safecode">SAFECode Compiler</a>
+</div>
+
+<div class="doc_text">
+<p>
+<a href="http://safecode.cs.illinois.edu">SAFECode</a> is a memory safe C
+compiler built using LLVM. It takes standard, unannotated C code, analyzes the
+code to ensure that memory accesses and array indexing operations are safe, and
+instruments the code with run-time checks when safety cannot be proven
+statically.
+</p>
+</div>
+
<!-- *********************************************************************** -->
<div class="doc_section">
Many subtle pointer invalidation bugs in Callgraph have been fixed and it now uses asserting value handles.
MC Disassembler (with blog post), MCInstPrinter. Many X86 backend and AsmPrinter simplifications
Various tools like llc and opt now read either .ll or .bc files as input.
-Malloc and free instructions got removed.
+Malloc and free instructions got removed, along with LowerAllocations pass.
compiler-rt support for ARM.
completely llvm-gcc NEON support.
Can transcode from GAS to intel syntax with "llvm-mc foo.s -output-asm-variant=1"
New LSR with full strength reduction mode
The most awesome sext / zext optimization pass. ?
+The ARM backend now has good support for ARMv4 backend (tested on StrongARM
+ hardware), previously only supported ARMv4T and newer.
+
+Defaults to RTTI off, packagers should build with make REQUIRE_RTTI=1.
CondProp pass removed (functionality merged into jump threading).
AndersAA got removed (from 2.7 or mainline?)
PredSimplify, LoopVR, GVNPRE got removed.
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
<ul>
-<li>The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430 and SystemZ backends are
- experimental.</li>
+<li>The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430, SystemZ and MicroBlaze
+ backends are experimental.</li>
<li>The <tt>llc</tt> "<tt>-filetype=asm</tt>" (the default) is the only
supported value for this option. The MachO writer is experimental, and
works much better in mainline SVN.</li>
</ul>
</div>
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ocaml-bindings">Known problems with the O'Caml bindings</a>
-</div>
-
-<div class="doc_text">
-
-<p>The <tt>Llvm.Linkage</tt> module is broken, and has incorrect values. Only
-<tt>Llvm.Linkage.External</tt>, <tt>Llvm.Linkage.Available_externally</tt>, and
-<tt>Llvm.Linkage.Link_once</tt> will be correct. If you need any of the other linkage
-modes, you'll have to write an external C library in order to expose the
-functionality. This has been fixed in the trunk.</p>
-</div>
-
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="additionalinfo">Additional Information</a>
projects / oota-llvm.git / blobdiff