LLVM is a shit compiler

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

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