4 ms·

I guess both. GCC is very good for compiling C/C++ to machine code. But if you want to write a new language and reuse an existing compiler pipeline (Rust, Swift

I guess both. GCC is very good for compiling C/C++ to machine code. But if you want to write a new language and reuse an existing compiler pipeline (Rust, Swift,..) or write a new tool based on a C++-parser (clang-format, clang-tiny, clangd,...) then LLVM is the way to go. LLVM-IR has enabled this nice separation between the language front-end and the compilation back-end. GCC could have done that too: they didn't for political reasons. Why? Someone could have used GCC's C++ front-end for its proprietary compilation pipeline. Today this is nearly impossible to change in GCC. There are also some other advantages for LLVM I like: it supports multiple architectures in a single binary. With GCC I need to compile the compiler either for x64 or arm but not both. GCC is still great but it's not surprising that LLVM is so successful.

baq 8y ago
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.
- jjuhl 8y ago
  The reverse has actually been done: https://dragonegg.llvm.org https://dragonegg.llvm.org
admax88q 8y ago
> 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.
- monocasa 8y ago
  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.
- readittwice 8y ago
  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.
  - gpderetta 8y ago
    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 https://gcc.gnu.org/wiki/GimpleFrontEnd I'm not sure how complete and usable it is though.
- rst 8y ago
  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/ https://lwn.net/Articles/582697/

baq 8y ago

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.

jjuhl 8y ago
The reverse has actually been done: https://dragonegg.llvm.org https://dragonegg.llvm.org

admax88q 8y ago

> 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.

monocasa 8y ago
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.
readittwice 8y ago
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.
- gpderetta 8y ago
  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 https://gcc.gnu.org/wiki/GimpleFrontEnd I'm not sure how complete and usable it is though.
rst 8y ago
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/ https://lwn.net/Articles/582697/