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

Comments

Re:Apparently not...

[Teese]

Low Level Virtual Machine

LWN alternative gcc article

[emj]

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

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