Very large and very complicated

The LLVM project has over 2 million lines, or 1.3 GB, of code. It's one of the largest projects on Github. It's so large that (at least at one point) you couldn't even push it to GitHub without workarounds.

With this, LLVM has a lot of unnecessary complexity. There are a lot of features your compiler isn't going to use unless it's C++, and a hobbyist or prototype compiler is definitely not going to use.

LLVM was created and is maintained by lots of talented developers, but nonetheless, a repo that large and complex is going to have issues. The following don't just apply to LLVM, but any large and complicated existing IR:

• Steep learning curve: Because LLVM is so complex, it takes a lot of effort to understand how to use. See the reference for llvm::Value: there are so many methods and subclasses it's hard to figure out which ones you want and which ones to ignore. There are also many subtle details which can trip up beginners (though off the top of my head I can't think of any examples, I remember this was the case).

• Lack of freedom: If you use LLVM as an IR you're practically required to adhere to LLVM conventions: e.g. Module/Function/BB/Instruction, using ...Builders like IRBuilder to construct values, using llvm Types and Values and Metadata. If you use your own IR, you can implement techniques and optimizations which are hard or straight-up impossible in LLVM.

• Framework problem (AKA more lack of freedom): It's not just in the IR. LLVM provides many generic types in the ADT module, including its own string and bit-vector; though you don't have to, it can be hard avoiding StringRef and BitVector in your own, non-IR code. More likely, you'll unintentionally write your AST and other earlier phases to be easier to translate into LLVM, which may make your language less unique more like C++. Like with most big frameworks, you could accidentally make your entire project revolve around using LLVM, especially if it's a small project and the majority of its code ends up being IR generation and LLVM integration.

• Large dependency: LLVM is 1.3 GB in source, but its install build is about 12 GB. This can probably be stripped and minified for a language which only relies on IR and assembly generation, but still, LLVM is going to take up a lot of space in your app's distribution.

• Bugs: In over 2 million lines of code there are definitely a lot of bugs. The GitHub repo has over 20,000 open issues.

• Hard to debug: Because LLVM is so large, when there's an internal bug or even when there's not, it's hard to figure out where the bug originated and how to fix it, because you don't understand LLVM's inner workings.

As mentioned, these problems don't just apply to LLVM, but any other large general-purpose IR. If you write your own IR, you have control: you can make a small IR which only supports your language's features, and is written in your compiler's code style and design philosophy. This IR will be easier to understand, easier to integrate, easier to extend with features which would be challenging or impossible with LLVM, and easier to debug.

Of course this skips over the many benefits of LLVM and other popular IRs, and challenges using a custom IR, like:

• Writing your own IR is hard

• LLVM has a very good design philosophy and encourages good practices which may be better than the ones you would use

• LLVM has plenty of general-purpose features and optimizations which would be hard to implement yourself

• LLVM has a team of experts fixing bugs and constantly making improvements, you won't have to maintain the IR yourself if you use LLVM

• and so on

But there are good reasons why you may want to write your own IR. And even if you do end up using LLVM, they are good issues to prepare for and avoid.

Using existing compiler infrastructure comes with a certain degree of either buying into the assumptions it makes or working around them. It may not be obvious at first what those assumptions are unless you're an expert in the relevant infrastructure already, so it can be difficult to defend against.

LLVM is maybe not too bad in that regard (and improving), but there have still been incidents such as for example optimizing out some infinite loops (making certain assumptions about forward progress in general) or infinite recursions as a default behaviour, requiring workarounds if your language does not allow those transformations (this may have changed by now).

Memory model, pointer provenance model (even the decision whether the concept of "provenance" is used at all), and floating point model, are also candidates for "sneaking into your language" via this backdoor rather than via a conscious decision. Into a compiler, really, but you may feel pressured to then retroactively bless such semantics to avoid having to work around them.

Transpilation is even more dangerous in this regard.

There's not always a whole lot you can do if the backend has bugs. Consider this recent issue for Zig, which discusses using their own backend instead of LLVM. One of the advantages listed is, and I quote:

• All our bugs are belong to us.

Further down the thread, a different user also brings up "the existence of many bugs that are LLVM's fault".

Speed (and other resource usage) probably is the biggest factor in many cases. LLVM, specifically, is slow.

Unfortunately, "help speed up the slow bits" is not a realistic answer, because LLVM's whole infrastructure is slow for an extremely good reason: It was designed primarily as a research and development platform.

You see, LLVM is not a compiler backend. It is a toolkit of pieces that you can build your own compiler backend from. It is designed for flexibility and generality, so that new compilation techniques and new platforms are relatively easy to add.

This flexibility and generality has a cost, and given that compilation speed (or lack thereof) is one of the most important things to a programmer, reducing that cost can pay off in terms of user experience.

It's hard to speak about all the IR frameworks/backends out there at once, but pretty much all of them are inflexible in some way and thus suitable only to certain types of languages and not others.

In particular, LLVM is kinda famous for being C/C++ centric, even Rust encountered a number of bugs/shortcomings/problems/inefficiencies that weren't an issue for C/C++ and thus were just hanging there for years unnoticed. All while Rust being low-level language pretty close to C/C++. The further you go the more trouble you encounter: it's well-known that adding a GC to LLVM is still hard and cumbersome. Implementing a lazy language is even harder and inefficient: LLVM backend for GHC Haskell do exist but it's slower than GCC through C--.

From the opposite side I've heard it's hard to add somewhat unconventional code generators to LLVM, like VLIW architectures. Again I've heard people more often use libFIRM for such projects (specialized microcontrollers, DSPs, etc.).

I guess you can find this or that shortcomings in any backend/framework. On the other hand, if you're implementing pretty conventional language, target common hardware and/or not aiming for ultimate performance and efficiency, any reasonable framework (LLVM, Cranelift, asmJIT, etc.) might serve you just fine and save enormous efforts.

Well, for my AEC-to-WebAssembly compiler, I decided not to use LLVM because I think WebAssembly is an even easier compilation target than LLVM is. To target LLVM, you need to understand what PHI is and what SSA is, whereas you don't need to understand those things if you are targetting WebAssembly.
Had I targeted x86 and/or ARM, I would have used LLVM, since x86 and ARM are not designed to be easy compilation targets (x86 and ARM are designed to be easy to implement in hardware, without a lot of consideration for the ease of making a compiler targeting them), but WebAssembly is designed to be an easy compilation target.

Languages which use a back end like LLVM will be limited to the choice of optimization semantics offered thereby. Compilers based upon LLVM, for example, seems to analyze the possibility of pointer aliasing by assuming that if some pointer X can be shown to equal some pointer Y, and Y is not based upon Z, then X isn't based upon Z. Consider the following:

int x[1],y[1];
int *volatile vp;
int test1(int *p)
{
    y[0] = 1;
    if (p==x+1)
        *p = 2;
    return y[0];
}
int test2(int *p)
{
    x[0] = 1;
    if (p==y+1)
        *p = 2;
    return x[0];
}
#include <stdio.h>
int main(void)
{
    int (*volatile vtest2)(int*) = test2;
    int rx = vtest2(x);
    printf("%d/%d\n", rx, x[0]);
}

There are two possible equally correct behaviors for this program: output 2/2 if x happens to immediately follow y or output 1/1 if it does not. Allthough test1 is never called, it seems to influence the placement of x immediately before y.

Both the above code, and an equivalent programmed in rust, would find that the passed pointer is equal to y+1 and write a value to it, without recognizing that the pointer could have been formed by taking the value of x. Perhaps the problem isn't with LLVM but a coincidental bug in both clang and the rust compiler, but it would seem more likely that the LLVM back-end semantics are involved.

One downside of using LLVM specifically is that it was not designed as a portable backend for multiple languages. As long as you're compiling something with more-or-less C semantics, you're fine, but try Pascal or Algol and similar languages and you'll find most of your development time goes into working around shortcomings such as the lack of nested procedure declarations. There are a few intermediate codes that target multiple languages but they're few and far between or very old, since Pascal or Algol style languages have been out of favour for some years now, and a lot of people brought up on C style languages don't even understand why you would want nested procedures or just how useful they actually are.