I only read part of the FAQ. I find the desire to keep the complexity low by limiting the compiler lines of code and not using LLVM interesting, but I wonder how practical it is. The FAQ admits that because of this, it generates slower code. So it shifts the complexity to the software codebase, by telling the users to “use assembly where needed”.
Seems a bit like Python’s philosophy of not introducing too much optimizations to prevent the runtime complexity from spiraling out of control.
I doubt it is a real problem for anything other than number crunching. I like to use tcc during development (which does very little, if any optimizations) to speed up compilation and I never noticed any regressions in performance, even for GUI software. Throughput just isn't that big of a deal for most applications (although latency and resource usage is, but that's not affected by choice of compiler).
I used SDL2. Not actively working on that project anymore, but I picked it due to requirements - fast startup, low latency, low memory usage, portability anywhere (linux on multiple distros, CPU architectures and multiple rendering backends, any Windows version from XP to 11...). C fits that very well IMO and I don't regret choosing it.
From what I heard LLVM seems to be not very great at keeping backwards compatibility and makes no guarantees that the IR (intermediate representation) stays the same. So I imagine it can be frustrating to have a moving target.
Plus it is a heavy dependency which means projects like writing a self-hosting OS in a month are much less realistic to achieve when your compiler relies on LLVM.
And not the least, the code generation is pretty slow. If your languages cares greatly about compile speed, which it should, this is a bummer.
So yeah, for many projects avoiding LLVM might be a good idea.
Seems a bit like Python’s philosophy of not introducing too much optimizations to prevent the runtime complexity from spiraling out of control.