LLVM 3.3 released

[Posted June 18, 2013 by corbet]

From:		Chris Lattner <clattner-AT-apple.com>
To:		llvm-announce-AT-cs.uiuc.edu
Subject:		LLVM 3.3 Release!
Date:		Mon, 17 Jun 2013 15:22:53 -0700
Message-ID:		<444E1AE4-9AD2-4F7F-93B9-DFA8180C3999@apple.com>

LLVM 3.3 is now available! Get it here: http://llvm.org/releases/

or read about it here:
http://llvm.org/releases/3.3/docs/ReleaseNotes.html

LLVM 3.3 is a big release: it adds new targets for the AArch64 and AMD R600 GPU architectures, adds
support for IBM's z/Architecture S390 systems, and major enhancements for the PowerPC backend
(including support for PowerPC 2.04/2.05/2.06 instructions, and an integrated assembler) and MIPS
targets.

Performance of code generated by LLVM 3.3 is substantially improved: the auto-vectorizer produces
much better code in many cases and is on by default at -O3, a new SLP vectorizer is available, and
many general improvements landed in this release. Independent evaluations show that LLVM 3.3's
performance exceeds that of LLVM 3.2 and of its primary competition on many benchmarks.

3.3 is also a major milestone for the Clang frontend: it is now fully C++'11 feature complete. At
this point, Clang is the only compiler to support the full C++'11 standard, including important
C++'11 library features like std::regex. Clang now supports Unicode characters in identifiers, the
Clang Static Analyzer supports several new checkers and can perform interprocedural analysis across
C++ constructor/destructor boundaries, and Clang even has a nice "C++'11 Migrator" tool to help
upgrade code to use C++'11 features and a "Clang Format" tool that plugs into vim and emacs (among
others) to auto-format your code.

LLVM 3.3 is the result of an incredible number of people working together over the last six months,
but this release would not be possible without our volunteer release team! Thanks to Bill Wendling
for shepherding the release, and to Ben Pope, Dimitry Andric, Nikola Smiljanic, Renato Golin,
Duncan Sands, Arnaud A. de Grandmaison, Sebastian Dreßler, Sylvestre Ledru, Pawel Worach, Tom
Stellard, Kevin Kim, and Erik Verbruggen for all of their contributions.

If you have questions or comments about this release, please contact the
LLVMdev mailing list! Onward to LLVM 3.4!

-Chris

LLVM 3.2 Release Announcement:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2012-Dec...

LLVM 3.3 released

Posted Jun 18, 2013 15:46 UTC (Tue) by intgr (subscriber, #39733) [Link] (9 responses)

Interesting...

> Support for C++11 ref-qualifiers has been added to GCC 4.8.1, making G++ the first C++ compiler to implement all the major language features of the C++11 standard

> At this point, Clang is the only compiler to support the full C++'11 standard

LLVM 3.3 released

Posted Jun 18, 2013 15:59 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

Depends on how one defines major and full support I guess. The actual status is at:

http://clang.llvm.org/cxx_status.html
http://gcc.gnu.org/projects/cxx1y.html

Neither implement *all* the features but that is not unexpected.

LLVM 3.3 released

Posted Jun 18, 2013 16:15 UTC (Tue) by cry_regarder (subscriber, #50545) [Link]

C++11 not C++1?:

http://gcc.gnu.org/projects/cxx0x.html

LLVM 3.3 released

Posted Jun 18, 2013 20:58 UTC (Tue) by talisein (subscriber, #31829) [Link] (6 responses)

GCC now implements the C++11 _language_, but as of yet falls short on the _standard library_.

LLVM now has both. And IMO is a more honest claim to using the word "complete"; confusion over the competing release announcements is not uncommon, and people who want to try C++11 on GCC will be confused when e.g. <regex> never works as expected--it is stubbed out, meaning it won't give a compile error, but there is no implementation.

To be fair, completing the language portion of the standard is an achievement that GCC deserves to trumpet, but the next sentence in their release announcement should have clarified "work continues on the standard library (help wanted)."

LLVM 3.3 released

Posted Jun 18, 2013 21:28 UTC (Tue) by rriggs (guest, #11598) [Link] (5 responses)

LLVM's "complete" C++ standard library doesn't count in my book until it runs on Linux. LLVM is still quite incomplete in that regard. (This is LWN after all -- with emphasis on the "L".)

LLVM 3.3 released

Posted Jun 18, 2013 22:27 UTC (Tue) by cmrx64 (guest, #89304) [Link] (4 responses)

libcxx runs quite well on Linux, when I tested it ~2 months ago.

LLVM 3.3 released

Posted Jun 19, 2013 2:36 UTC (Wed) by hummassa (subscriber, #307) [Link] (3 responses)

There is no .deb at http://llvm.org/apt/, where did you get libc++ from?

LLVM 3.3 released

Posted Jun 19, 2013 12:21 UTC (Wed) by Jonno (subscriber, #49613) [Link] (1 responses)

libc++ has been included in Debian experimental for almost a year, and in unstable/testing since May.

Debs can be found at: http://ftp.debian.org/debian/pool/main/libc/libc++/

LLVM 3.3 released

Posted Jun 19, 2013 20:43 UTC (Wed) by hummassa (subscriber, #307) [Link]

That was *really* useful. Many thanks!

LLVM 3.3 released

Posted Jun 19, 2013 13:23 UTC (Wed) by cmrx64 (guest, #89304) [Link]

I built it myself, along with libcxxrt

LLVM 3.3 released

Posted Jun 18, 2013 16:36 UTC (Tue) by farsley72 (guest, #91481) [Link] (4 responses)

Quality of clang generated code still seems to be subpar compared to gcc:
http://llvm.org/bugs/show_bug.cgi?id=16358

LLVM 3.3 released

Posted Jun 18, 2013 18:49 UTC (Tue) by kreijack (guest, #43513) [Link] (3 responses)

Before comparing the "quality of code" we should define the metrics. IMHO the judgement parameters should be, in order of importance:
- code correctness
- standard conformity
- performance in the worst case
- performance in the best case

I separate the worst and the best case performance, because I prefer a compiler which doesn't show the *WORST* performance in *ANY* case to one which has the *BEST* performance in *SOME* case.

The bug reports a bad performance against a single case. Something to be investigate, but IMHO not sufficient to take any judgement.

LLVM 3.3 released

Posted Jun 19, 2013 1:14 UTC (Wed) by farsley72 (guest, #91481) [Link] (2 responses)

Disregarding an inconvenient data point doesn't make it any less valid.

It has taken gcc a long while to evolve a good optimizer and code generator. llvm is still a "young" project in comparison, so when llvm/clang folks already start claiming "independent evaluations show that LLVM 3.3's performance exceeds that of (...) its primary competition on many benchmarks", we have a right to call them on their claims.

The bug shows that clang has difficulties optimizing (vectorizing) loops that are slightly more involved than garden variety, resulting in ~50% slower code than gcc.

LLVM 3.3 released

Posted Jun 19, 2013 18:00 UTC (Wed) by kreijack (guest, #43513) [Link] (1 responses)

I am quite sure that there are a lot of benchmark where LLVM beat GCC and/or the opposite. And sure, the regression reported should be investigated by the CLANG team.

However, what I stated is that the "Quality of clang generated code" is different from a low performance in a single case.

Does anyone know if there is an organic performances comparative between the two compilers ? Something with a rationale behind ?

LLVM 3.3 released

Posted Jun 19, 2013 22:37 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]

Phoronix has done a lot of gcc vs. llvm benchmarking. Certainly you could raise some issues about parts of their methodology, but their general approach seems fair and they provide enough information to duplicate or critique their work. They generally show that the two compilers are quite competitive other than llvm's lack of OpenMP support which affects some benchmarks severely.

However, there's a risk in focusing on well-known benchmarks because competitive compiler projects do so. It's better to benchmark your own applications, code that the compiler developers haven't seen before, to really understand who's better, and I would expect on average that llvm will compile a bit faster while g++ will produce slightly better code, but the variance will be high enough that it might be the other way around on your code. Both compilers have gotten a lot better recently thanks to the competition.

It certainly appears that llvm has caught up to gcc for the most part. At this point, llvm has regex in C++11 and g++ lacks it; g++ has OpenMP which llvm lacks. Whether this matters depends on whether you need the missing feature.