LLVM 2.2 Released

performance geek writes "LLVM 2.2 was released yesterday! This is the thirteenth public release of the open-source compiler that started as a GCC fork. LLVM supports several aggressive optimizations, in compile-, link- and run-time, and often produces faster (1.5-3x) code than GCC. It is also much faster than GCC at compiling (despite the slow link-time optimizations). Gentoo users are already trying to build the whole system with the LLVM toolchain to get the extra performance bit."

Re:Apparently not...

[Teese]

Low Level Virtual Machine [wikipedia.org]

LWN alternative gcc article

[emj]

LWN has discussion [lwn.net] on this, and there is a nice video presentation of LLVM 2.0 [google.com] as well. Cool thing, but as they say it isn't really about replacing GCC.

Re:Apparently not...

[Frozen Void]

http://en.wikipedia.org/wiki/LLVM [wikipedia.org]
Wikipedia, learn to use it.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Apparently not...

[cbart387]

Agreed. I've always been taught that you introduce the full meaning of an acronym before you use it. The acronym may make sense to you, but the reader may not have been exposed to it. This is especially applicable on a tech site, where acronyms are rampant. I'm not even including the acronyms seen only on slashdot (which are very off putting to a first time user by the way). Remember: EVERYONE started as a beginner.

... just a pet peeve of mine that I can do a mini-rant on without being off-topic ;)

Re:Does it do inline asm yet?

[AcidPenguin9873]

LLVM has supported inline asm since release 1.7, and the support has steadily been getting better at each release, with major improvements in 1.8 and 1.9.

http://llvm.org/releases/1.7/docs/ReleaseNotes.html [llvm.org]
http://llvm.org/releases/ [llvm.org]

The only problem with the x86 inline asm support in 2.2 is the lack of support for the x87 floating point stack in the inline asm register constraints. See "Known Problems" in the 2.2 release notes.

Re:Extra Performance

[SanityInAnarchy]

Actually, I was correcting the point. TFS claims 1.5x-3x speed improvement over gcc.

Of course, TFS was also dead wrong about Gentoo users trying to build the whole system. Apparently there's an ebuild to install llvm, which seems like an obvious thing to do. There's also mention of Mesa intending to switch to llvm, and other projects might follow, but those are isolated programs, no more shocking or revolutionary than the fact that Eclipse is written in Java.

Re:Good reporting there, submitter

[LizardKing]

That's why Apple used a BSD base as opposed to a Linux base for Mac OS X.

No, it's because MacOS X is a continuation of NeXTstep, which was based on a BSD userland and Mach kernel (itself originally developed from the BSD Unix kernel circa version 4.3). At the time NeXTstep was originally developed, Linux didn't exist and the GNU userland was still in its infancy. In addition, I've never seen any evidence that Apple considered a move to a Linux base for MacOS X, and considering how solid NeXTstep and OpenStep were I'd be surprised if they did. Licensing would have been an unlikely issue anyway, as NeXTstep always shipped with GCC as part of the development tools and there are a number of GNU tools in MasOS X.

Re:Good reporting there, submitter

[Anonymous Coward]

Did you read a word of the post you're replying to?

Mac OS 9 wasn't Unix based.

So what? Who said it was? And who cares anyway? It's completely and utterly irrelevant, because OS X isn't derived from MacOS 9, it's derived from NeXTStep.

When they jumped to a Unix base with OS X, Linux had been well established.

But they didn't jump to a Unix base; they replaced MacOS with a new operating system based on NeXTStep. NeXTStep was first developed in the 1980s, many years before Linux even existed at all, let alone became established.

They choose a BSD base because of the license.

No, they didn't choose a BSD base at all. They chose NeXTStep, which happened to come with a BSD base. They never had any reason to consider a Linux base, because they already had a perfectly good Unix base. There was no choice made because there was no reason to make a choice.

If they chose a Linux base, OS X would have to be completely open source, and that was never going to fly.

Bullshit. You don't know what you're talking about. There is no reason whatsoever why you can't run a closed-source userland on a GPL kernel.

Re:Good reporting there, submitter

[larry bagina]

Exactly! From the clang readme. Half of these things are a nice feature for XCode/IDE integration.

III. Current advantages over GCC:

  * Column numbers are fully tracked (no 256 col limit, no GCC-style pruning).
  * All diagnostics have column numbers, includes 'caret diagnostics', and they
      highlight regions of interesting code (e.g. the LHS and RHS of a binop).
  * Full diagnostic customization by client (can format diagnostics however they
      like, e.g. in an IDE or refactoring tool) through DiagnosticClient interface.
  * Built as a framework, can be reused by multiple tools.
  * All languages supported linked into same library (no cc1,cc1obj, ...).
  * mmap's code in read-only, does not dirty the pages like GCC (mem footprint).
  * LLVM License, can be linked into non-GPL projects.
  * Full diagnostic control, per diagnostic. Diagnostics are identified by ID.
  * Significantly faster than GCC at semantic analysis, parsing, preprocessing
      and lexing.
  * Defers exposing platform-specific stuff to as late as possible, tracks use of
      platform-specific features (e.g. #ifdef PPC) to allow 'portable bytecodes'.
  * The lexer doesn't rely on the "lexer hack": it has no notion of scope and
      does not categorize identifiers as types or variables -- this is up to the
      parser to decide.

Potential Future Features:

  * Fine grained diag control within the source (#pragma enable/disable warning).
  * Better token tracking within macros? (Token came from this line, which is
      a macro argument instantiated here, recursively instantiated here).
  * Fast #import with a module system.
  * Dependency tracking: change to header file doesn't recompile every function
      that texually depends on it: recompile only those functions that need it.
      This is aka 'incremental parsing'.

Re:Extra Performance

[Just Some Guy]

There isn't that much performance hidden in there.

Fortunately for us, compiler researchers say you're wrong. LLVM takes the Java-like approach of seeing what parts of your code can be optimized by gathering runtime profiling information, then using that to dynamically recompile parts of your code that really need it. I'd be surprised if that kind of system couldn't squeeze out quite a bit more performance.