Last month we attended the Euro-LLVM meeting, a conference for the LLVM developer community in Europe. We were presenting our poster of our work on the MAchine Guided Energy Efficient Compiler framework, which is nearing the first release version.
The meeting was held in Edinburgh, hosted by the University Department of Computer Science. Edinburgh is one of the oldest Universities in the world and has a very strong record in Computer Science; while perhaps best known for the late Prof. Robin Milner’s theoretical work on parallel and multi-processor computing, it also has a solid reputation for more practical engineering, particularly in processor design and simulation. A visit is always a rewarding intellectual adventure.
This was a big meeting — the best part of 200 attendees. Indeed, if I have a concern about the success of conferences in free and open source software, it is that their size starts to interfere with their role as forums for technical discussion and progress. An event of this this scale gets on the radar of corporate marketing departments and, while they are generous in their financial backing, their presence can sometimes inhibit truly free discussion. I don’t think this was a major problem at this year’s meeting, but the signs of a problem in the making were there: more formal presentations and no proper “birds-of-a-feather” (BoF) sessions.
They key themes that I picked out of this meeting were threefold:
- LLVM is becoming mainstream in two areas: ARM architectures (plenty of senior ARM and Qualcomm attendees) and graphics systems, particularly using OpenCL (big attendance from Sony and CodePlay). It remains a popular choice for PhD students, being easier to pick up than GCC. However, I was surprised that its adoption by OpenBSD as the default compiler was not discussed.
- LLVM is not yet breaking out of its core architecture families of ARM, Intel and PowerPC. This may be a side-effect of the dominance of a relatively small number of large corporations, but I had hoped to hear about LLVM on processors that are not 32- or 64-bit Stanford architectures with lots of registers. Indeed, looking at the talks, it seems that LLVM is the compiler if you want to experiment with different front ends — for example, the talk on LLVM for Erlang — rather than targeting a very wide range of architectures.
- The LLVM community sees its work on C++11 and the upcoming C++14 as a key advantage (implicitly, “we’re better than GCC on this“). It can only be good for industry to have competition in standards compliance.
I was pleased to see several attendees who are also active participants in the GNU Tools Cauldron. It can be tempting to consider LLVM and GCC as head-to-head competitors, but in reality they are both complex modern compilers, and the front-line engineers are much more interested in taking compiler technology forward, than in tribal wards defending just one particular project.
That is Embecosm’s view. We develop both GCC and LLVM compilers for customers. And indeed, notwithstanding my second point above, if you want LLVM for an embedded system, possibly with less than 32-bit addressing, or where address and code spaces are separate or maybe even word addressed, it can be done. And Embecosm are the people to do it for you.
