The problem is that "weird CPUs and embedded systems" are not mainstream platforms, nor do they have a lot of money behind them (particularly for open source development). Hence, there is little motivation and/or resources for anyone to develop a new backend for LLVM when a mature GCC backend already exists. Moreover, the LLVM developers are weary to accept new backends for niche platforms when there is no guarantee that they will be maintained in the future.
Exactly - often the GCC branch is barely maintained by whoever is selling the CPU/chip, and it is patches against a specific version that you must use, or it goes haywire.
At least with GCC they can sometimes merge the patches.
Hm, is it so much easier to write an LLVM back-end than a GCC back-end? I haven't looked into GCC's code gen infrastructure that much, but I looked into making a new back-end to LLVM some time ago and it seemed extremely complex and entirely undocumented. All guidance I found on it basically amounted to, "copy an existing back-end and bang it against a rock until you've made it generate the machine code you need". And it certainly wasn't a case of having clean and simple enough code to make documentation unnecessary. It would honestly surprise me if GCC is more difficult to add a back-end to.
I don't have much experience with writing a custom gcc backend, but my experience with LLVM is that its model ends up being a somewhat poor fit for smaller or weirder architectures. For example, LLVM has this annoying tendency to really aggressively promote the size of everything--if you have a 32-bit core with 64-bit memory indexing, LLVM tends to make anything that eventually becomes a memory index a 64-bit computation, even if it would be more efficient to keep everything as 32-bit.
GCC still for Linux distributions using glibc or any other library with many "GCCisms". Also, I'm not sure whether or not Clang is ABI compatible enough for enterprise customers with some rather extreme backwards compatibility requirements. Still, I can imagine a future where glibc can be built with Clang, possibly even one where llvm-libc is "good enough" for many users.
I do remember reading about LTO not working properly, you're either unable to link the kernel with LTO, or get a buggy binary which crashes at runtime. Doesn't look like much effort has been put into solving it, maybe it's just too large a task.
