5 ms·

C is more portable than the LLVM IR though. So you get an inferior in some ways, but a more portable program as your compiler's output. And if you want to debug

by _yosefk 11y ago

C is more portable than the LLVM IR though. So you get an inferior in some ways, but a more portable program as your compiler's output. And if you want to debug in a debugger that uses a proprietary format rather than DWARF, C will work better than LLVM, etc. C is an OK target for a small new language; it's probably too crummy for a big, successful one (C++ certainly is one data point here!) But IMO for 90% of new "small" languages that can choose between C and LLVM IR, C isn't obviously the worse choice.

pcwalton 11y ago
Is it more portable in a way that matters though? LLVM targets x86, x86-64, ARM32, ARM64, PowerPC, MIPS, SPARC, Hexagon, System z, TI MSP430, and XCore, as well as NVIDIA and AMD GPUs, and has some unofficial forks that target other niche architectures like AVR. If you aren't targeting one of those architectures, you're in a really niche space. If you are in that niche space (i.e. you know that you absolutely have to target some architecture), and you don't have source to your compiler, by all means target C though--though I really wonder if it isn't worth just fixing up the LLVM C backend. (LLVM hasn't been able to find a maintainer for that backend because so few people are on architectures that aren't supported natively by LLVM, which says something to me about how few people need support for those architectures.)
- TazeTSchnitzel 11y ago
  LLVM can even target the web (emscripten).
- comex 11y ago
  > Is it more portable in a way that matters though? A few months ago when I was trying to compile swiftc's IR with emscripten, I would have said "definitely yes". It didn't work both because of a LLVM version mismatch and because, well, the NaCl backend passes were apparently only tested on IR generated by Clang - random differences in what swiftc generated, like using 'add' with a constant right hand side instead of get-element-ptr, not simplifying struct returns to return-via-pointer-argument, etc. made it variously abort or outright crash. As you know, Rust has never really worked with it either due to the version mismatch. Admittedly, though, that's mainly emscripten's fault, and I expect the new WebAssembly backend in trunk to be much more robust. Other than that, a few reasons I can think of to want to compile to C: - Performance. Other compiler backends often produce more efficient code than LLVM; not always, but it's nice to be able to test several independent production-quality C compilers and pick the fastest, while with LLVM IR you're stuck with what you have. Same goes for compilation speed, though LLVM usually ranks well at that, and even working around optimizer bugs. - Windows support for LLVM is still not up to par yet. Supposedly it will be in the near future. - (edit) Easier to integrate with unusual platform-specific compilation modes, like C++/CLI or Apple's LLVM bitcode distribution (well, that is LLVM, but imagine in the future someone comes up with a similar system based on a different compiler). - You can distribute the C output from your compiler, and others can use it without having to work your compiler into their build process. Like distributing object files, but those only work on one platform, while C works anywhere. (Caveat: compilers often need to know data layout, which in practice means you might need to have separate C outputs for 64-bit and 32-bit pointer sizes, and not support any more exotic data representations. But that's still way more portable than an object file.) Notably, even if you only need to distribute to people using LLVM, LLVM IR is not designed to be cross-platform. Incidentally, for this reason, I'd love if someone made a Rust to C compiler, preferably working on the AST level to avoid the unreadable spaghetti that the LLVM C backend used to generate. It's easier to say "swap out this insecure C library with a secure Rust library" (to a larger C/C++ program) if doing so is a matter of swapping C files - distributing 'binaries' is suboptimal from a maintainability perspective, but not much worse than, e.g., SQLite's "amalgamation" distribution.
  - Ono-Sendai 11y ago
    LLVM works fine on Windows. Clang is not feature complete on Windows however.
  - pcwalton 11y ago
    > - Performance. Other compiler backends often produce more efficient code than LLVM I wouldn't say "often" here. LLVM's compiler backend is top-notch and is hard to beat. Often it comes down to random register allocation or scheduling differences. > - Windows support for LLVM is still not up to par yet. Supposedly it will be in the near future. What are you referring to in particular? The only thing I can really think of is exception handling, and that got overhauled recently for MSVC compatibility. PDB was an issue too, but that's gotten fixed and now LLVM can output PDB. I can't think of much that's left... > - You can distribute the C output from your compiler, and others can use it without having to work your compiler into their build process. That is a legitimate advantage. But on the whole I think that it's outweighed by the downsides of compiling to C.
    - comex 11y ago
      > PDB was an issue too, but that's gotten fixed and now LLVM can output PDB. I can't think of much that's left... This is what I was referring to. The RFC from a Microsoft employee on full CodeView (what gets compiled to PDB) support was posted three months ago, but AFAIK the implementation is still in progress. The preexisting support for CodeView is described by the documentation as "minimal" as it contains only line tables.
      - pcwalton 11y ago
        But when compiling to C you can't do much better than #line. So it doesn't strike me of much of an argument in favor of compiling to C.
  - pcwalton 11y ago
    Oh, and regarding the request for a Rust AST to C compiler, I hope that doesn't happen for a number of reasons. First, it undoes the work we're doing on MIR, which is very important (you couldn't run MIR-level optimizations, the borrow check and codegen would be at high risk of divergence, we'd have to take a big backwards step to serializing ASTs for generics, etc.) Second, it'd be very hard to dodge C's undefined behavior: think of what we'd have to do to make signed integer overflow crash cleanly instead of leading to UB, just to name one particularly egregious problem...
- geon 11y ago
  The author is a game developer. I don't know what platfirms he worked with, but the console world isn't known for their great compiler support. You are pretty much limited to whatever the official (nda ridden) sdk privides.

by _yosefk 11y ago

pcwalton 11y ago

Is it more portable in a way that matters though? LLVM targets x86, x86-64, ARM32, ARM64, PowerPC, MIPS, SPARC, Hexagon, System z, TI MSP430, and XCore, as well as NVIDIA and AMD GPUs, and has some unofficial forks that target other niche architectures like AVR. If you aren't targeting one of those architectures, you're in a really niche space. If you are in that niche space (i.e. you know that you absolutely have to target some architecture), and you don't have source to your compiler, by all means target C though--though I really wonder if it isn't worth just fixing up the LLVM C backend. (LLVM hasn't been able to find a maintainer for that backend because so few people are on architectures that aren't supported natively by LLVM, which says something to me about how few people need support for those architectures.)

TazeTSchnitzel 11y ago
LLVM can even target the web (emscripten).
comex 11y ago
> Is it more portable in a way that matters though? A few months ago when I was trying to compile swiftc's IR with emscripten, I would have said "definitely yes". It didn't work both because of a LLVM version mismatch and because, well, the NaCl backend passes were apparently only tested on IR generated by Clang - random differences in what swiftc generated, like using 'add' with a constant right hand side instead of get-element-ptr, not simplifying struct returns to return-via-pointer-argument, etc. made it variously abort or outright crash. As you know, Rust has never really worked with it either due to the version mismatch. Admittedly, though, that's mainly emscripten's fault, and I expect the new WebAssembly backend in trunk to be much more robust. Other than that, a few reasons I can think of to want to compile to C: - Performance. Other compiler backends often produce more efficient code than LLVM; not always, but it's nice to be able to test several independent production-quality C compilers and pick the fastest, while with LLVM IR you're stuck with what you have. Same goes for compilation speed, though LLVM usually ranks well at that, and even working around optimizer bugs. - Windows support for LLVM is still not up to par yet. Supposedly it will be in the near future. - (edit) Easier to integrate with unusual platform-specific compilation modes, like C++/CLI or Apple's LLVM bitcode distribution (well, that is LLVM, but imagine in the future someone comes up with a similar system based on a different compiler). - You can distribute the C output from your compiler, and others can use it without having to work your compiler into their build process. Like distributing object files, but those only work on one platform, while C works anywhere. (Caveat: compilers often need to know data layout, which in practice means you might need to have separate C outputs for 64-bit and 32-bit pointer sizes, and not support any more exotic data representations. But that's still way more portable than an object file.) Notably, even if you only need to distribute to people using LLVM, LLVM IR is not designed to be cross-platform. Incidentally, for this reason, I'd love if someone made a Rust to C compiler, preferably working on the AST level to avoid the unreadable spaghetti that the LLVM C backend used to generate. It's easier to say "swap out this insecure C library with a secure Rust library" (to a larger C/C++ program) if doing so is a matter of swapping C files - distributing 'binaries' is suboptimal from a maintainability perspective, but not much worse than, e.g., SQLite's "amalgamation" distribution.
- Ono-Sendai 11y ago
  LLVM works fine on Windows. Clang is not feature complete on Windows however.
- pcwalton 11y ago
  > - Performance. Other compiler backends often produce more efficient code than LLVM I wouldn't say "often" here. LLVM's compiler backend is top-notch and is hard to beat. Often it comes down to random register allocation or scheduling differences. > - Windows support for LLVM is still not up to par yet. Supposedly it will be in the near future. What are you referring to in particular? The only thing I can really think of is exception handling, and that got overhauled recently for MSVC compatibility. PDB was an issue too, but that's gotten fixed and now LLVM can output PDB. I can't think of much that's left... > - You can distribute the C output from your compiler, and others can use it without having to work your compiler into their build process. That is a legitimate advantage. But on the whole I think that it's outweighed by the downsides of compiling to C.
  - comex 11y ago
    > PDB was an issue too, but that's gotten fixed and now LLVM can output PDB. I can't think of much that's left... This is what I was referring to. The RFC from a Microsoft employee on full CodeView (what gets compiled to PDB) support was posted three months ago, but AFAIK the implementation is still in progress. The preexisting support for CodeView is described by the documentation as "minimal" as it contains only line tables.
    - pcwalton 11y ago
      But when compiling to C you can't do much better than #line. So it doesn't strike me of much of an argument in favor of compiling to C.
- pcwalton 11y ago
  Oh, and regarding the request for a Rust AST to C compiler, I hope that doesn't happen for a number of reasons. First, it undoes the work we're doing on MIR, which is very important (you couldn't run MIR-level optimizations, the borrow check and codegen would be at high risk of divergence, we'd have to take a big backwards step to serializing ASTs for generics, etc.) Second, it'd be very hard to dodge C's undefined behavior: think of what we'd have to do to make signed integer overflow crash cleanly instead of leading to UB, just to name one particularly egregious problem...
geon 11y ago
The author is a game developer. I don't know what platfirms he worked with, but the console world isn't known for their great compiler support. You are pretty much limited to whatever the official (nda ridden) sdk privides.