Slashdot Mirror


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

5 of 128 comments (clear)

  1. Re:Apparently not... by Teese · · Score: 4, Informative
    --
    "I'm a Genius!"*


    *Not an actual Genius
  2. LWN alternative gcc article by emj · · Score: 4, Informative

    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.

  3. Comment removed by account_deleted · · Score: 3, Informative

    Comment removed based on user account deletion

  4. Re:Apparently not... by cbart387 · · Score: 3, Informative

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

    --
    Lack of planning on your part does not constitute an emergency on mine.
  5. Re:Good reporting there, submitter by larry+bagina · · Score: 5, Informative

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

    --
    Do you even lift?

    These aren't the 'roids you're looking for.