Are there any technical reasons FreeBSD are choosing LLVM as their compiler infrastructure, or does the whole matter boil down to the eternal GNU/GPL vs. BSD licenses?
Summary: The primary reason for switching from GCC to Clang is the incompatibility of GCC's GPL v3 license with the goals of the FreeBSD project. There are also political issues to do with corporate investment, as well as user base requirements. Finally, there are expected technical advantages to do with standards compliance and ease of debugging. Real world performance improvements in compilation and execution are code-specific and debatable; cases can be made for both compilers.
FreeBSD and the GPL: FreeBSD has an uneasy relationship with the GPL. BSD-license advocates believe that truly free software has no usage restrictions. GPL advocates believe that restrictions are necessary in order to protect software freedom, and specifically that the ability to create non-free software from free software is an unjust form of power rather than a freedom. The FreeBSD project, where possible, tries to avoid the use of the GPL:
FreeBSD and the GPL v3: The GPL v3 explicitly forbids the so-called Tivoisation of code, a loophole in the GPL v2 which enabled hardware restrictions to disallow otherwise legal software modifications by users. Closing this loophole was an unacceptable step for many in the FreeBSD community:
Because of GCC's move to the GPL v3, FreeBSD was forced to remain using GCC 4.2.1 (GPL v2), which was released way back in 2007, and is now significantly outdated. The fact that FreeBSD did not move to use more modern versions of GCC, even with the additional maintenance headaches of running an old compiler and backporting fixes, gives some idea of the strength of the requirement to avoid the GPL v3. The C compiler is a major component of the FreeBSD base, and "one of the (tentative) goals for FreeBSD 10 is a GPL-free base system".
Corporate investment: Like many major open source projects, FreeBSD receives funding and development work from corporations. Although the extent to which FreeBSD is funded or given development by Apple is not easily discoverable, there is considerable overlap because Apple's Darwin OS makes use of substantial BSD-originated kernel code. Additionally, Clang itself was originally an in-house Apple project, before being open-sourced in 2007. Since corporate resources are a key enabler of the FreeBSD project, meeting sponsor needs is probably a significant real-world driver.
Userbase: FreeBSD is an attractive open source option for many companies, because the licensing is simple, unrestrictive and unlikely to lead to lawsuits. With the arrival of GPL v3 and the new anti-Tivoisation provisions, it has been suggested that there is an accelerating, vendor-driven trend towards more permissive licenses. Since FreeBSD's perceived advantage to commercial entities lies in its permissive license, there is increasing pressure from the corporate user base to move away from GCC, and the GPL in general.
Issues with GCC: Apart from the license, using GCC has some perceived issues. GCC is not fully-standards compliant, and has many extensions not found in ISO standard C. At over 3 million lines of code, it is also "one of the most complex and free/open source software projects". This complexity makes distro-level code modification a challenging task.
Technical advantages: Clang does have some technical advantages compared to GCC. Most notable are much more informative error messages and an explicitly designed API for IDEs, refactoring and source code analysis tools. Although the Clang website presents plots indicating much more efficient compilation and memory usage, real world results are quite variable, and broadly in line with GCC performance. In general, Clang-produced binaries run more slowly than the equivalent GCC binaries:
Conclusion: It's highly unlikely that compilation efficiency would be a significant motivator to take the substantial risk of moving a large project like FreeBSD to an entirely new compiler toolchain, particularly when binary performance is lacking. However, the situation was not really tenable. Given a choice between 1) running an out-of-date GCC, 2) Moving to a modern GCC and being forced to use a license incompatible with the goals of the project or 3) moving to a stable BSD-licensed compiler, the decision was probably inevitable. Bear in mind that this only applies to the base system, and support from the distribution; nothing prevents a user from installing and using a modern GCC on their FreeBSD box themselves.
One thing worth considering is that FreeBSD is currently using GCC 4.2.1 as noted in ire_and_curses answer thus the performance comparisons aren't of 4.5 or even 4.6 aren't truly relevant to the project. Therefore, the questions you should be asking are:
If Clang lags behind the current GCC but is still light years ahead of the implemented GCC in the project then their decision to evolve is well warranted and truly inspired.
Even though GCC is GPLv3, the resulting binaries produced by GCC never had any license constraint. In clear you can use GCC to build software that falls under the license you want. Even the C library that comes with GCC and that is included in the binary is license-free. http://www.gnu.org/licenses/gcc-exception-faq.html
Section 2 of the GNU GPLv3:
“Eligible” means that the compilation does not involve both GCC and GPL-incompatible software. That's not a restriction: BSD-licensed software can be used in the build process involving GNU GCC.
As you can see, contrary to what has been said above, there is no REAL license-related reason to move away from GCC as there is no incompatibility with using GCC inside FreeBSD.
The real reason behind this change is political and opportunistic:
These facts creates an opportunity for FreeBSD to move away from GCC and get rid of it: they're not actually legally compelled to, as they could well still use GCC to build free or BSD-licensed software, but they want to stick to the "all BSD licensed software" philosophy.
I'm no expert, but my understanding is Clang/LLVM uses fewer resources than GCC and is quicker.
If you're running an environment where you need to build a lot of stuff, a lot of times, that performance may turn into real savings in energy costs and time. If it's real.