LLVM: The Bad Parts

Summary

A few years ago, I wrote a blog post on design issues in LLVM IR. Since then, one of these issues has been fixed fully (opaque pointers migration), one has been mostly fixed (constant expression removal), and one is well on the way towards being fixed (ptradd migration). This time I’m going to be more ambitious and not stop at three issues. Of course, not all of these issues are of equal importance, and how important they are depends on who you ask. In the interest of brevity, I will mostly just explain what the problem is, and not discuss what possible solutions would be. Finally, I should probably point out that this is written from my perspective as the lead maintainer of the LLVM project: This is not a list of reasons to not use LLVM, it’s a list of opportunities to improve LLVM. High level issues Review capacity Unlike many other open-source projects, LLVM certainly does not suffer from a lack of contributors. There are thousands of contributors and the distribution is relatively flat (that is, it’s not the case that a small handful of people is responsible for the majority of contributions.) What LLVM does suffer from is insufficient review capacity. There are a lot more people writing code than reviewing it. This is somewhat unsurprising, as code review requires more expertise than writing code, and may not provide immediate value to the person reviewing (or their employer). Lack of review capacity makes for a bad contributor experience, and can also result in bad changes making their way into the codebase. The way this usually works out is that someone puts up a PR, then fails to get a qualified review for a long period of time, and then one of their coworkers (who is not a qualified reviewer for that area) ends up rubberstamping the PR. A related problem is that LLVM has a somewhat peculiar contribution model where it’s the responsibility of the PR author to request reviewers. This is especially problematic for new contributors, who don’t know whom to reque...