llvm 2.0 release announcement [draft]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

llvm 2.0 release announcement [draft]

Chris Lattner-2

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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm 2.0 release announcement [draft]

Lauro Ramos Venancio

  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



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm 2.0 release announcement [draft]

Jeff Cohen
In reply to this post by Chris Lattner-2
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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm 2.0 release announcement [draft]

Chris Lattner
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: llvm 2.0 release announcement [draft]

Evan Cheng-2

On May 14, 2007, at 10:13 PM, Chris Lattner wrote:

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

It's fine with me if we don't say anything about x86-64 large code  
model. There was enough to get the JIT working on Mac. But I am  
relying on others to test / fix other platforms.  There are plenty  
left to do before we can claim true large code model support.

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

I don't have a freebsd box to test. Please reduce the test case to  
a .bc file and I'll be happy to look at it.

Evan

>
> -Chris
>
> --
> http://nondot.org/sabre/
> http://llvm.org/
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev