> LLVM-IR has enabled this nice separation between the language front-end and the compilation back-end.

You're implying that GCC doesn't have a separation between language front-end and compilation back-end, but that's not true.

GCC has a consistent internal representation known as GENERIC where the front-ends and back-ends meet just like LLVM.

What I mean: As a compiler writer you can't just create GIMPLE-IR and then pass it to GCC. You always need to go through GENERIC, which is actually intended to be the AST of your language. Of course you could argue that you treat GENERIC not as an AST but something similar to LLVM-IR and keep your language AST outside of GCC. But does anyone do that? The reason for that is that the IR doesn't contain ALL the information, there is also some global state stored in global variables, etc. Also since the IR is only internal it is not as well-defined as LLVM's IR.

This missing separation is even a problem for writing tests in GCC: Often it would be quite easy to write a small program in GIMPLE-IR (or RTL) and test your optimization pass against it. But you can't write GIMPLE-IR (it needs to go through GENERIC all the time), so you need to write a C file that is then translated into the IR you want to test again. This is sometimes not so easy with all that different optimization passes that run before your pass and hopefully that doesn't change in the future either.... There was some work on this (I don't know about the current status) but almost all of GCC's tests are still integration tests against C files (I think they addressed this by extending the C-front end to be able to parse functions marked with __gimple as Gimple-IR). Also GIMPLE didn't start as a separate IR. It started as a more restricted tree-structure. Even today operands are still tree's and optimization passes are called tree-<something>.c.

With LLVM I can write a toy compiler that outputs LLVM IR with printf and then just pipe it into llc to compile it. That's pretty cool. I didn't want to imply that GCC has NO separation between IRs but the whole story is much messier compared to LLVM. Which is actually fine, LLVM is much younger than GCC and could learn a lot from it. And GCC is still pretty great in the use cases it was intended for.

I think GCC has been much more willing to opening up the compiler recently (almost exclusively because of the competition from clang). For gimple there is this:

https://gcc.gnu.org/wiki/GimpleFrontEnd

I'm not sure how complete and usable it is though.

And GIMPLE... and RTL...

And there's three separate forms of GIMPLE while you're at it.

It's way easier to work with LLVM IR.

Unfortunately, this IR level is not readily accessible to third parties, for political reasons -- RMS does not want to make it easy for third-party code to integrate with GCC at this level, for fear that some of the code that uses that interface might be proprietary. See, e.g.,

https://lwn.net/Articles/582697/

you're of course right except the OP asked about clang and not llvm. clang frontend could generate postprocessed c and pass it into gcc for whatever that's worth.

The reverse has actually been done: https://dragonegg.llvm.org