LLVM is a shit compiler

It's worse than GCC 4.5 in terms of speed, and that says A LOT

>>1
nipaaaaaaaaaaaaaa~~~~~~~~

you should've written your own when you were 12 and what is this

LLVM is not a compiler. HTH, HAND.

>>4

Hanus?

--enable-optimized
    Enables optimized compilation (debugging symbols are removed and GCC optimization flags are enabled).
    Note that this is the default setting if you are using the LLVM distribution. The default behavior of an
    Subversion checkout is to use an unoptimized build (also known as a debug build).

>>6
Vroom! Vroooom!

GCC has a lot of momentum, but at some point LLVM should start gaining mind share among compiler researchers. Who really wants to work with the GCC code?

>>6
Who gives a shit about Subversion?

>>9
If you want to try Clang you do.

>should start gaining mind share among compiler researchers
Just like academic languages

optimized code > compiler speed

>>12
This more than anything else.  Hell, if compilation takes so long as to be noticeable, just let it run while you're at the store or sleeping or whatever.

>>12-13
http://xkcd.com/303/

>>14
Rob Pike wants to end those days. Fuck that guy.

http://www.freebsd.org/cgi/ports.cgi?query=clang&stype=name&sektion=all
Requires: gcc-4.2.5.20090325_4
lol

>>10
There are a few distros that have clang packages that aren't built from subversion, including OS X, FreeBSD, and Arch Linux.

>>14
Fuck off, Randall.

>>18
Is it sad that I can tell a bolded spoilered Randall from the width alone?

>>19
Are you viewing /prague/ in monospace?

>>20
If he were, it'd be miraculous that he could tell its font-width.

>>20
No, but I'm not using disproportional font either.

I've tried LLVM mingw and it doesn't compile anything:
..\llc: test.c:4:1: error: expected top-level entity
#include <stdio.h>
^

LLC is the bytecode-> x86 compiler
http://adrianboeing.blogspot.com/2009/05/llvm-for-beginners-windows.html

Ok, not impressed. Code 15% slower than GCC

They should port JavaScript to LLVM

>>26
They target C/C++ programmers. This is stupid, since established  native compilers which don't need a vm/bytecode can outperform them easily(unlike VM languages)

>>26
Already done. Except the LLVM is ported to JavaScript.
http://github.com/omo/jsllc

The two problems with LLVM: its in Sepples and sponsored by Apple.

>>29
If you've seen the kind of shit that the FSF pulls in its management of GCC, you'd welcome a different organization, even Apple, backing your compiler of choice.  The FSF sabotages the modularity of GCC out of ideological devotion to the GPL.  Why does GCC have no accessible intermediate language?  Because then someone could write a closed-source frontend, backend, or optimization stage for it.  GCC is an utter piece of shit if you want to try and add support for new languages or platforms.

Linuxare: To what extent does the basic architecture of GCC need changes to support the language front-ends, such as the new GCC Java compiler?

Richard: I don't know anything about what's happening with the Java compiler. I stopped dealing with GCC around 1992 and I don't know what changes, if any, were needed. Some changes were needed mainly in the tree data structure, which is what programs get parsed into. Occasionally, when you handle a language that has the kind of construct that hasn't been handled before, if there's no way to represent it with the existing tree data structure, you need to add something so you can represent it. Things like methods and core methods needed a way to be represented, so we added them.

Linuxcare: Does GCC still use a LISP-like intermediary language?

Richard: Printed syntax is what's LISP-like. It's not really LISP-like in the sense that it consists of tupelos that point to a number of other tupelos, which is not by any means a new format for priority use. It's printed out in a LISP-like syntax because that makes it easy to work with in EMACS.

Linuxcare: How did you come to choose LISP as the EMACS engine?

Richard: LISP is the most powerful programming language, and if you want an interpreter, LISP is the best. None of the other languages come anywhere near LISP in their power. The most exciting things about LISP are read, eval, and print. If you look at other languages, they have no equivalent for any of those.

This thread has been beautifully segued into the following:
Name: Anonymous
Email:
Subject: Typing LISP in lowercase letters

Message: It doesn't work.

>>32
Lisp.

>>33
It just doesn't work.

Haxus The Lexus

Haxus the Lexer

>>31
tupelos

The most exciting things about LISP are read, eval, and print. If you look at other languages, they have no equivalent for any of those.
JavaScript: prompt, eval, alert
Perl: <>, eval, print

"no equivalent" MY ANUS

>>38
You are very wrong. Either you are trolling, or you have no idea how Lisp works.

read parses a line of input into an s-expression. It does not return a string.
eval evaluates an already-parsed s-expression. It does not operate on strings.
print outputs an s-expression. It does not process strings. (That is, (print "hello") will output "hello" with the quotation marks intact.)

>>38
has never used Lisp if he thinks those are eqv?

>>38
you mena print eval(<>) or die "FUCKING NIGGERS\n";

>>41
back to /vip/ please

>>42
nah

>>39
Those languages use strings (which are more general and powerful than s-expressions) where LISP uses s-expressions.

>>44
W-D

>>44
FrozenVoid?

>>44
weak

>>47
u jus got ownd bitx

Jesus, GCC really is NOT THAT BAD, it even shows bench marks that are faster than Intel in some cases. Grow up and leave.

>>49
Did you really need to bump a dead thread to declare this?

>>49
That's right. GCC works and is adequate. Certain metrics may compare worse to other compilers and that's fine to me. If I require something specific, I can get GCC fixed to meet that requirement.

>>51
How about adding support for a new language to GCC?  That, sir, is an utter PITA.  LLVM exposes its back end to anyone who wants to use it.  (Insert anal sex joke here.)

EXPOSE MY ANUS

>>52
I can't help but notice the 'PITA'/exposed back end parallel. GCC: dom, LLVM: sub -? Mayhaps they will hook up and make sexytimes.

Y'all ignoring the fact that clang's error reporting facilities are much, MUCH better than the garbage gcc (or worse, g++) throws back at you.

http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html

There's your killer feature.

Also, gcc had a decade head start. Since LLVM's backend isn't intentionally obfuscated like gcc's and uses a clean IR that's especially designed to facilitate optimization, it will eventually overtake gcc in speed and reliability.

LLVM isn't worse than GCC. If you build it for release mode and use the Clang front-end, it's both a faster compiler and generates much faster code (granted that you build native machine executables, not LLVM bytecode executables).

The fact that you claim otherwise just shows that you're an amateur.

GCC also really sucks at ARM code generation still after all of these years, and Clang/LLVM is really shining here. I recently came up with a fast 3-term cross-product using NEON intrinsics.


float32x4_t cross3(float32x4_t v1, float32x4_t v2) {
    float32x4x2_t xxyyzz1 = vzipq_f32(v1, v1);
    float32x4x2_t xxyyzz2 = vzipq_f32(v2, v2);   
    float32x2_t xx1 = vget_low_f32(xxyyzz1.val[0]);
    float32x2_t yy1 = vget_high_f32(xxyyzz1.val[0]);   
    float32x2_t zz1 = vget_low_f32(xxyyzz1.val[1]);
    float32x2_t xx2 = vget_low_f32(xxyyzz2.val[0]);
    float32x2_t yy2 = vget_high_f32(xxyyzz2.val[0]);   
    float32x2_t zz2 = vget_low_f32(xxyyzz2.val[1]);

    float32x2_t x = vmul_f32(yy1, zz2); // x' = v1.y * v2.z
    float32x2_t y = vmul_f32(zz1, xx2); // x' = v1.z * v2.x 
    float32x2_t z = vmul_f32(xx1, yy2); // x' = v1.x * v2.y
    x = vmls_f32(x, zz1, yy2);          // x' = x' - v1.z * v2.y
    y = vmls_f32(y, xx1, zz2);          // y' = y' - v1.x * v2.z
    z = vmls_f32(z, yy1, xx2);          // z' = z' - v1.y * v2.x

    float32x2x2_t result = vuzp_f32(x, y);
    return vcombine_f32(result.val[0], z);
}

GCC 4.5 generates the following shit:


        vmov    d27, r2, r3
        vmov    d20, d6
        vmov    d2, d26
        vmov    d3, d7
        vzip.32 q2, q3
        vmov    d17, d27
        vmov    d24, d6
        vmov    d25, d1
        vzip.32 q12, q10
        vmov    d22, d5
        vmov    d23, d2
        vmov    d18, d1
        vmov    d19, d20
        vmul.f32 q1, q11, q12
        vmov    d16, d4
        vmov    d17, d5
        vmul.f32 d16, d20, d6
        vmul.f32 d18, d17, d18
        vmul.f32 d17, d23, d5
        vmov    d18, d1
        vmov    d19, d20
        vmls.f32 d16, d3, d5
        vmls.f32 d18, d0, d6
        vmov    d1, d24
        vmls.f32 d17, d1, d4

And Clang/LLVM generates the optimal sequence, exactly what I would have wrote if I were to do it by hand:


        vmov    q1, q0
        vmov    q3, q2
        vzip.32 q0, q1
        vzip.32 q2, q3
        vmul.f32 d16, d1, d6
        vmul.f32 d18, d3, d4
        vmul.f32 d17, d0, d5
        vmls.f32 d16, d3, d5
        vmls.f32 d18, d0, d6
        vmls.f32 d17, d1, d4

GCC still wins at general program speed(big programs not benchmarks).
IIRC llvm incurs 15-10% speed loss vs GCC in most of them(and about -10% more if we compare with Intel C++ which has somewhat better optimizer).

>>57
Sounds like you're citing the recent SPEC2000 benchmarks which used the GCC-LLVM frontend instead of Clang.

>>57
I really don't buy those numbers. A 10-(25)% speed reduction would place it *way* down the ranks.

http://multimedia.cx/eggs/intel-beats-up-gcc/
http://www.phoronix.com/scan.php?page=article&item=apple_llvm_gcc&num=2

>>60
That isn't new information to anyone.