Yes: memory management in the compiler is interesting. There's a complicated graph of pointer references. Most of the time the compiler is building something relatively small, so we don't need to bother cleaning up, we just exit without freeing it all (for speed). But when e.g. building with Link Time Optimization, we can use large amounts of RAM, so a garbage-collection can be needed.
I'm be surprised if it didn't have something related to memory allocation and free. Open64 (previously the SGI compiler) has an "arena" memory allocator to improve memory locality and make freeing scratch memory easier. Looks like LLVM uses arena allocation, too.
Some people swear by arenas, some people swear by GCs, some swear by stacks, and others swear by malloc. There are probably people who swear by things I didn't list. Compiler writers are people, too, and so they swear by many memory allocation styles.
When I first started writing compilers, I learned the craft from people who happened to also be GC zealots, and they insisted that it was not possible to write a compiler any other way.
I remember once talking to a VM hacker who wrote compilers in C++ and was shocked that it was even possible to write a compiler in Java.
Then I saw LLVM, which mostly just relies on new/delete and an intuitive ownership model. I've done that ever since.
But as a memory management nerd I have to say that there are some advantages to every approach. Arenas are cheap and intuitive. GCs mean you don't have to care about lifetimes. Malloc/free minimizes object drag. Pick what you like and don't let anyone tell you that any one of these approaches is inherently better than the others.
LLVM does it only for very particular things. Otherwise it is using malloc a lot. The ownership is interesting as well, as some pieces are "leaked" to the LLVMContext, which has some granularity: it owns the module you're working on, so can't be destroyed before you don't need the module anymore.
Middlebrow dismissal? Memory management is a common concern across languages, and languages which do not include garbage collection tend to host a variety of approaches depending on the author and what sort of thing they were building.
Writing C code that uses garbage collection does not equal Common Lisp.
Not meant as a dismissal at all. I just noted that the phenomenon in which big complex C programs evolve into using features of higher level languages (like garbage collection instead of the regular malloc+free approach) is well known. Games are famous for using frame-bound arenas.
GCC wanted to run on anything that had enough RAM, so it's written in C (and now I think C++). I think a language with garbage collection and ML style pattern matching would be nicer for writing a compiler, and I don't think porting the GC runtime to every platform is that much work, but Microsoft didn't rewrite their compilers in F# and Oracle didn't rewrite the Java compilers in Scala, so maybe I'm missing something.
First, it's easier often to opt in to higher level functionality when useful then to opt out of high level language features. As for why no one ported compilers yet... that's a ton of work, even if they wanted to, for no benefit.
It's interesting that GCC has a custom GC.