LLVM is a great idea, congratulations. Do you mind if I give you a little bit of constructive criticism from the point of view of a developer who would like to use LLVM as a back-end?
I will write this email from the point of view of MS Windows, but the same applies to MacOS and Linux.
LLVM is difficult/awkward to use in a real-world environment/situation. To solve this problem, take a hint from the developer of the popular SQLite:
On that page, you can see that sqlite.org provides a precompiled sqlite DLL for MS Windows. That is great, because it means that a developer can simply grab the compiled DLL, and start using it, incorporating it into their project, without having to go through all of the difficulty of compiling SQLite (or LLVM) themselves, and without having to make their program awkwardly invoke the LLVM command-line tools.
Furthermore, an LLVM DLL should go "all the way". Your "llc" tool is supposed to be a back-end tool, but it is more like an almost-back-end tool, because it generates assembly language to a text file, rather than a native code executable program file.
So we need a precompiled LLVM DLL that can be invoked, passing in LLVM bytecode, and it should generate a native code ready-to-execute MS Windows .EXE or .DLL file. This would make it more practical to use in a real-world situation.
GCC needs to be cut out of the back-end picture. Currently, it is impossible to use LLVM as a back-end without GCC because GCC is still required to convert the assembly language .S text file into a native machine code .EXE or .DLL file.
It is fine that you are using GCC as an example front-end, but unfortunately you are also using it in the back-end as well. A back-end that is totally free of GCC is needed.
Thanks for reading.