Don't compile to C.
First, there are cases where compiling other languages to C or C++ is better than via LLVM; interoperability and portability are two (yes, C and C++ are more portable than LLVM).
Second, I'm not really talking about compiling some wildly different language to C++. I'm talking about some simple syntactic sugar. The same syntactic sugar that would be in an existing C or C++ compiler's front end, except instead of adding it to all the frontends in the world and waiting years, I'd like to implement it just once and now.
People bring up obscure platforms (though, interestingly, I can't recall anybody actually naming one of those platforms) all the time as motivation for compiling to C. But if you really need to do that, you can always revive the LLVM C backend. The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms.
In your opinion. This isn't a fact. For example, I know first hand of code that has to compile with compilers that are not in the set { gcc, clang, msvc }. What do I do then? (Oh, and those compilers are closed-source).
> You'll end up wanting to just use clang's front end to help you
Probably, although there are other options too
> and at that point why not just modify clang itself?
The changes I make, if useful to the community, would probably end up back in clang. But they would also remain a separate tool, because of all those other pesky compilers I work with.
> you can always revive the LLVM C backend
I'm not sure how that helps me; not only does it seem a terribly roundabout way to get what I'm looking for (instead of sugar -> c++ -> my c++ compiler, you are proposing sugar -> clang -> llvm -> c -> my c compiler), but I don't think objects produced by that pipeline would link with C++ objects produced from my native compilers, among other issues.
> The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms.
Or, is it evidence that people using more obscure platforms (we're talking fortune 500 companies here) stick to languages that exist on their platforms for various reasons?
C and C++ are more portable then their own compiler's backend? LLVM is clang/clang++'s assembler
I get what your saying if you compile to C it can be more portable. But then you need to compile to some C standard.
K&R C? ANSI C? C90? C99? C11? Why not have a compiler flag for each? What about embedded C? What companies embedded C?
I can repeat this for C++
Compiling to C/C++ in a platform and standard agnostic way is impossible.
Lots of languages can give you a dump in 1 standard of C. You can't specify what C standard, or what platform to output outside of ARM/x64. NIM, Cython, C++ (via clang), [Ada/Cobalt/Fortran]-GCC, Perl, Agol, Oracle PL/SQL only support x86_64 and ARM.
Your argument was
interoperability and portability
2) You have no portability gain as you have 3 choices x86, x64, and ARM. All of which Rust already supports.
Also your main request
$ rustc your_program.rs --emit llvm-ir
$ llc -march=c -o your_program.c your_program.ll
$ rustc your_program.rs --emit llvm-ir
$ llc -march=cpp -o your_program.cpp your_program.llRust is not interoperable with C++ as far as I know, and even if it was, I'm not interested in Rust for this discussion for reasons I've mentioned elsewhere.
The LLVM C backend was removed. Julia devs have a version that supports the LLVM bit code that they require, but I believe it is not everything LLVM can produce.
I was under the impression that march=cpp output C++ code that rebuilt the IR, not implemented the source program.
Thanks for the advice, although none of it really applies to what I'm suggesting.
kind of paradox to say that
Mine was worded as a polite request and his was worded as a command.
If you don't want to wait, want to experiment with something else, learn a new language, etc., Rust is awesome.
Obviously the counter argument to this is, "but there's 30+ years of C++ in production", but be honest, who actually wants to work on a 30 year old codebase?
Why do I have to wait for every compiler on every system I want to build on to update to some future standard when things could be done now across the board in many cases?
It's certainly pleasing to be able to sit down and write something from scratch or nearly from scratch. But it can be equally pleasing to extend a multi-million line codebase to do something new, or to enable the codebase as a whole to do something new/better.
(I want it to compile to C++ so I can use the compilers I use and it can interoperate with the C++ code it has to interoperate with and C++ programmers that work on this code wouldn't have to learn more than a few extras that might make their lives easier).