As the original author of that benchmark, I should point out that that was LLVM SVN (unreleased) against GCC 4.8 & 4.9 - I couldn't get GCC 5.0 SVN to build, so it's possible 5.0 will be faster again than LLVM in certain situations.
However, I would also say that generally I've found LLVM is now producing faster code than GCC in most code I've tested both compilers with.
That is very interesting, because LLVM developers themselves admit LLVM generates slower code than GCC (in average). This is plain if you read LLVM Developers' Meeting talks.
I think it is completely possible that LLVM developers are using wrong benchmarks. Benchmarks are mostly SPEC and some large Google C++ codebases; in some sense both are quite atypical. But then, entire problem is to understand how typical codebases look like.
I can hopefully settle this (as a developer of both).
Assuming we stick to x86/x64, nowadays (literally, let's say as of January 2015) GCC and LLVM are within the noise for most people on most code (IE 1-2% of each other).
You can certainly find benchmarks were LLVM does badly. Some are important to some people, some aren't.
It is harder to find benchmarks where GCC does badly.
Small benchmarks can go either way, but for large codebase (especially C++) inliner is more important than just about anything else. So GCC wins, because it has better inliner.
There are many measures of benchmark sizes. One important measure is size of codes that account for 99% of execution time. If your codebase is a million lines but your hotspot is a thousand lines, benchmark result is sensitive to optimization quirks and in some sense benchmark is small.
However, I would also say that generally I've found LLVM is now producing faster code than GCC in most code I've tested both compilers with.