Hi Everyone,
It is getting to be that time again. I've scoured llvm-commits and
collected a list of some of the major features we've developed since
the last status update (from Feb 21). Please take a look and send me
(off list) additions, feedback, corrections, etc. As usual, if I
missed something, it's probably because there is such a huge amount
of stuff happening, please let me know!
Finally, I'm planning to start hacking on the release notes (llvm/
docs/ReleaseNotes.html), but there is a lot of great stuff to be
mentioned and doing so takes a lot of time. I would appreciate all
help I can get with this. The first place to start is by merging the
major contents of this announcement and the previous one into the
release notes. If you maintain a target, or any other portion of the
compiler, please ensure the release notes adequately reflect the
state of your component.
Thanks!
-Chris
---- 8< -------- 8< ----
... intro
... LLVM is being used for a broad variety of academic research
projects (e.g. see http://llvm.org/pubs/ ) and industrial development
projects (see http://llvm.org/Users.html )
... Plug the dev mtg: http://llvm.org/DevMtgMay2007.html
New Features:
x. Reid and Sheng contributed IR, optimizer, and interpreter
support for arbitrary bitwidth integers which have sizes > 64 bits.
This means that LLVM IR can now express operations on 31337-bit wide
integers, for example (however, for most people, 128-bit wide
integers on 64-bit targets will be the most useful new integer
type). Currently neither llvm-gcc nor the native code generators
support non-standard width integers.
x. The LLVM 1.x "bytecode" format has been replaced with a
completely new binary representation, named 'bitcode'. Because we
plan to maintain binary compatibility between LLVM 2.x ".bc" files,
this is an important change to get right. Bitcode brings a number of
advantages to the LLVM over the old bytecode format. It is denser
(files are smaller), more extensible, requires less memory to read,
is easier to keep backwards compatible (so LLVM 2.5 will read 2.0 .bc
files), and has many other nice features. Please see http://llvm.org/
docs/BitCodeFormat.html for more details.
x. Christopher Lamb added support for alignment values on load and
store instructions, finishing off PR400. This allows the IR to
express loads that are not sufficiently aligned (e.g. due to pragma
packed) or to capture extra alignment information.
x. Roman Samoilov contributed a new MSIL backend to LLVM. llc -
march=msil will now turn LLVM into MSIL (".net") bytecode. This is
still fairly early development with a number of limitations.
x. Anton and Lauro implemented support for 'protected visibility'
in ELF.
x. Lauro implemented support for Thread Local Storage with the
__thread keyword, and added codegen support for Linux on X86 and ARM.
x. Anton implemented support for ELF symbol aliases.
x. Reid contributed support for 'polymorphic intrinsics', allowing
things like llvm.ctpop to work on arbitrary width integers.
llvm-gcc Improvements:
x. Duncan Sands contributed many enhancements to llvm-gcc, some of
which are language independent and others that are aimed towards
better Ada support. He made improvements to NON_LVALUE_EXPR, arrays
with non-zero base, structs with variable sized fields,
VIEW_CONVERT_EXPR, CEIL_DIV_EXPR, and many other things.
x. Devang, Duncan and Andrew all contributed many patches to
improve "attribute packed" support in the CFE, and handle many other
obscure struct layout cases correctly.
Optimizer Improvements:
x. Devang implemented support for a new LoopPass class, implemented
passmanager support for it, and converted existing loop xforms to use
it. See: http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass
x. Devang contributed a new loop rotation pass, which converts "for
loops" into "do/while loops", where the condition is at the
bottom of
the loop.
x. Devang added support that allows ModulePasses to use the result
of FunctionPasses. This requires holding multiple FunctionPasses
(e.g. dominator info) in memory at a time.
x. Owen and Devang both worked to eliminate the [Post]DominatorSet
classes from LLVM, switching clients to use the far-more-efficient
ETForest class instead. Owen removed the ImmediateDominator class,
switching clients to use DominatorTree instead. These changes reduce
memory usage and speed up the optimizer.
Target-Independent Code Generator Enhancements:
x. Jim, Anton and Duncan contributed many enhancements and
improvements to C++/Ada zero-cost DWARF exception handling support.
While it is not yet solid, it is mostly complete and just in need of
continued bug fixes and optimizations at this point. Jim wrote
http://llvm.org/docs/ExceptionHandling.html to describe the approach.
x. Many bugfixes and other improvements have been made to inline
asm support. The two large missing features are support for 80-bit
floating point stack registers on X86 (PR879), and support for inline
asm in the C backend (PR802). If you run into other issues, please
report them.
x. Evan implemented a new register scavenger, which is useful for
finding free registers after register allocation. This is useful
when rewriting frame references on RISC targets, for example.
x. LLVM now supports describing target calling conventions
explicitly in .td files, reducing the amount of C++ code that needs
to be written for a port.
x. Evan contributed heuristics to avoid coallescing vregs with very
large live ranges to physregs. This effectively pinned the physreg
for the entire live range of the vreg, which was very bad for code
quality.
x. Evan implemented support for very simple (but still very useful)
rematerialization in the register allocator, enough to move
instructions like "load immediate" and constant pool loads.
x. Anton significantly improved 'switch' lowering, improving
codegen for sparse switches that have dense subregions, and
implemented support for the shift/and trick.
x. The code generator now has more accurate and general hooks for
describing addressing modes ("isLegalAddressingMode") to
optimizations like loop strength reduction and code sinking.
x. Dale and Evan contributed several improvements to the Loop
Strength Reduction pass, and added support for sinking expressions
across blocks to reduce register pressure.
x. Evan added support for tracking physreg sub-registers and super-
registers in the code generator, as well as extensive register
allocator changes to track them.
x. Nate contributed initial support for virtreg sub-registers. See
PR1350 for more information.
Target-Specific Code Generator Enhancements:
x. Nicolas Geoffray contributed support for the Linux/ppc ABI, and
the linux/ppc JIT is fully functional now. llvm-gcc and static
compilation are not fully supported yet though.
x. Bill contributed support for the X86 MMX instruction set.
x. Dale contributed many enhancements to the ARM constant island
pass, making ARM codegen significantly better for large functions.
x. Anton fixed several bugs in DWARF debug emission on linux and
cygwin/mingw. Debugging basically works on these targets now.
x. Lauro contributed support for the ARM AAPCS and EABI ABIs and
PIC codegen on arm/linux.
x. Dale implemented more aggressive size analysis for ARM inline
asm strings.
x. Evan added support for the X86-64 large code model to the JIT,
which is useful if JIT'd function bodies are more than 2G away from
library functions.
x. Raul Herbster contributed fixes for DWARF debug info generation
on arm/linux.
Other Improvements:
x. Anton and Reid are working to migrate from CVS to SVN in June:
See http://llvm.org/SVNMigration.html This will allow us to host
llvm-gcc and llvm in the same repository again!
x. Lauro contributed support to llvm-test for running on low-memory
or slow machines (make SMALL_PROBLEM_SIZE=1).
x. Jeff contributed many portability fixes to the llvm-test
testsuite, and has done a great job keeping llvm itself building with
MS Visual Studio.
... outro
In addition to the features above, this this release also includes
hundreds of bug fixes, minor optimization improvements, compile-time
speedups, etc. LLVM has literally compiled millions of lines of code
in several different environments.
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2007-February/
000021.html
If you have any questions or comments, please contact the LLVMdev
mailing list (llvmdev at cs.uiuc.edu)!
-Chris
Lauro Ramos Venancio
2007-May-14 12:19 UTC
[LLVMdev] llvm 2.0 release announcement [draft]
> > > x. Lauro implemented support for Thread Local Storage with the > __thread keyword, and added codegen support for Linux on X86 and ARM.Thread Local Storage is not fully functional on ARM because the ARM TLS llvm-gcc patch wasn't applied yet. So, I think the __thread keyword support for ARM will appear on LLVM 2.1. x. Lauro contributed support for the ARM AAPCS and EABI ABIs and> PIC codegen on arm/linux.ARM AAPCS and EABI are the same ABI. AAPCS or EABI => arm-linux-gnueabi APCS or OABI => arm-linux-gnu and arm-apple-darwin Lauro -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070514/95f5949e/attachment.html>
Chris Lattner wrote:> x. Roman Samoilov contributed a new MSIL backend to LLVM. llc - > march=msil will now turn LLVM into MSIL (".net") bytecode. This is > still fairly early development with a number of limitations. >This ought not be advertised to the world. It is not useful for any purpose. Not only can it not do virtual method calls, as I previously pointed out, it can't even instantiate objects! And there is a good reason why the implementation cannot do so: it is extremely difficult to recover high-level MSIL semantics from low-level LLVM IR. I am not convinced it is even possible. It's as hard as reconstructing a C++ class declaration from LLVM IR.> x. Evan added support for the X86-64 large code model to the JIT, > which is useful if JIT'd function bodies are more than 2G away from > library functions. >Not true. See PR1299, which still hasn't been fixed.
On Mon, 14 May 2007, Jeff Cohen wrote:> Chris Lattner wrote: >> x. Roman Samoilov contributed a new MSIL backend to LLVM. llc - >> march=msil will now turn LLVM into MSIL (".net") bytecode. This is still >> fairly early development with a number of limitations.> This ought not be advertised to the world. It is not useful for any purpose.Jeff, I'm well aware of your opinions in this matter.> Not only can it not do virtual method calls, as I previously pointed out, it > can't even instantiate objects! And there is a good reason why the > implementation cannot do so: it is extremely difficult to recover high-level > MSIL semantics from low-level LLVM IR. I am not convinced it is even > possible. It's as hard as reconstructing a C++ class declaration from LLVM > IR.The full power of MSIL isn't available through the msil backend, and it is not very useful if you're converting from C code. I say "This is still fairly early development with a number of limitations.", which I believe is accurate. Even though you apparently don't like this work, please don't disparage it. Other people have put time and effort into it, and it could grow to be an important component in the future.>> x. Evan added support for the X86-64 large code model to the JIT, which >> is useful if JIT'd function bodies are more than 2G away from library >> functions.> Not true. See PR1299, which still hasn't been fixed.Actually, it is true - PR1299 not being fixed does not mean the work wasn't done. I did not claim that he fixed every possible x86-64 jit bug, certainly not on platforms we don't have available to test. I asked Evan to look into this PR, but if you'd like it fixed, the only certain wait to get it fixed is to do it yourself (or pay someone else to do it, I suppose). -Chris -- http://nondot.org/sabre/ http://llvm.org/