Oh another thing, consider this question that some people will be asking: Why not use GCC to do what LLVM does, and skip the hassle of using LLVM entirely? ESPECIALLY considering that LLVM cannot be used without GCC. Even if you are using LLVM as a back-end only, for compiling LLVM bytecode only, GCC is still required to convert the "llc" output assembly .S file into a ready-to-execute native machine code .EXE or .DLL file. Thus if LLVM is an incomplete back-end replacement for GCC, why not just use the normal version of GCC? I do understand the LLVM project and I think it is great and very worthwhile, but while LLVM cannot be used as a complete back-end by itself, then GCC is a more attractive solution for our project. See, in our project, we have a front-end compiler. For input to the back-end, we can generate LLVM bytecode, or we can generate C source code, and then we need it converted to a native machine code .EXE or DLL ready to load and run. So you see, either GCC or LLVM can be used as our back-end. Now what advantage does LLVM have that will entice us to pick LLVM over GCC? LLVM is smaller? Not really, because LLVM still requires the use of GCC for the .S file, as I said above. LLVM would be a considerably more attractive solution than GCC *if* the following were true: (a) LLVM could be used as a back-end without use of GCC. Meaning LLVM by itself can generate a ready-to-execute .EXE or .DLL file. (b) LLVM was provided as a precompiled DLL, not only as command-line tools.
On May 10, 2008, at 3:06 AM, kr512 wrote:> > Oh another thing, consider this question that some people > will be asking: Why not use GCC to do what LLVM does, and > skip the hassle of using LLVM entirely?If you'd prefer to use GCC, go for it. No one is forcing you to use LLVM.> ESPECIALLY considering that LLVM cannot be used without GCC. > Even if you are using LLVM as a back-end only, for compiling > LLVM bytecode only, GCC is still required to convert the > "llc" output assembly .S file into a ready-to-execute native > machine code .EXE or .DLL file.You are seriously ignorant of what LLVM is all about. Please go inform yourself. -Chris
[snip] 1. Not all language paradigms can be specified in C, hence, you need more raw control. 2. GCC is not the only assembler / linker on windoze. I believe M$ provides assemblers / linkers so people can develop on windoze. At least they did back in the early 80's when I was using DOS. GCC not required :) Ter
On May 10, 2008, at 3:06 AM, kr512 wrote:> > Oh another thing, consider this question that some people > will be asking: Why not use GCC to do what LLVM does, and > skip the hassle of using LLVM entirely? > > ESPECIALLY considering that LLVM cannot be used without GCC. > Even if you are using LLVM as a back-end only, for compiling > LLVM bytecode only, GCC is still required to convert the > "llc" output assembly .S file into a ready-to-execute native > machine code .EXE or .DLL file. >I don't know about your computer, by mine comes with an assembler. GCC invokes this assembler, and I can invoke it from the command line just fine.> Thus if LLVM is an incomplete back-end replacement for GCC, > why not just use the normal version of GCC? > > I do understand the LLVM project and I think it is great and > very worthwhile,This I agree with. -bw> but while LLVM cannot be used as a complete > back-end by itself, then GCC is a more attractive solution > for our project. > > See, in our project, we have a front-end compiler. For > input to the back-end, we can generate LLVM bytecode, or we > can generate C source code, and then we need it converted to > a native machine code .EXE or DLL ready to load and run. So > you see, either GCC or LLVM can be used as our back-end. > > Now what advantage does LLVM have that will entice us to > pick LLVM over GCC? LLVM is smaller? Not really, because > LLVM still requires the use of GCC for the .S file, as I > said above. > > LLVM would be a considerably more attractive solution than > GCC *if* the following were true: > (a) LLVM could be used as a back-end without use of GCC. > Meaning LLVM by itself can generate a ready-to-execute .EXE > or .DLL file. > (b) LLVM was provided as a precompiled DLL, not only as > command-line tools. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
kr512 wrote:> Oh another thing, consider this question that some people > will be asking: Why not use GCC to do what LLVM does, and > skip the hassle of using LLVM entirely? > > ESPECIALLY considering that LLVM cannot be used without GCC. > Even if you are using LLVM as a back-end only, for compiling > LLVM bytecode only, GCC is still required to convert the > "llc" output assembly .S file into a ready-to-execute native > machine code .EXE or .DLL file. > > Thus if LLVM is an incomplete back-end replacement for GCC, > why not just use the normal version of GCC? > > I do understand the LLVM project and I think it is great and > very worthwhile, but while LLVM cannot be used as a complete > back-end by itself, then GCC is a more attractive solution > for our project. > > See, in our project, we have a front-end compiler. For > input to the back-end, we can generate LLVM bytecode, or we > can generate C source code, and then we need it converted to > a native machine code .EXE or DLL ready to load and run. So > you see, either GCC or LLVM can be used as our back-end. > > Now what advantage does LLVM have that will entice us to > pick LLVM over GCC? LLVM is smaller? Not really, because > LLVM still requires the use of GCC for the .S file, as I > said above. > > LLVM would be a considerably more attractive solution than > GCC *if* the following were true: > (a) LLVM could be used as a back-end without use of GCC. > Meaning LLVM by itself can generate a ready-to-execute .EXE > or .DLL file. >As other have stated, most systems come with an assembler (even GCC relies on an assembler to generate native code). While I agree that generating ELF object files would be a nice feature, the presence of an assembler on all supported platforms has made this a lower priority, so (as far as I know), no one has done it. If people are interested in finishing the work that has already been started on it, we gratefully accept patches.> (b) LLVM was provided as a precompiled DLL, not only as > command-line tools. >LLVM is actually designed as a set of libraries with a (in my humble opinion) relatively easy to use API. The command line tools are only wrappers, so to speak, around these libraries. You can write your own program that directly links in and uses the LLVM libraries to perform code generation, program analysis, optimization, and even JIT compiling. Your LLVM tools do not need to pass input through the opt or llc programs; you can link and use the libraries that opt and llc use to do their jobs. About the only thing we don't plan to do (as far as I know) is precompile the LLVM libraries. We prefer source distributions (because LLVM supports many different OS/hardware combinations, and LLVM is easy to compile on most platforms). For more information on the LLVM APIs, I'd refer you to the following: Programmer's Manual: http://llvm.org/docs/ProgrammersManual.html LLVM Tutorial: http://llvm.org/docs/tutorial/ LLVM Libraries (out of date, but gives you an idea of how LLVM's structure supports DLLs): http://llvm.org/docs/UsingLibraries.html Doxygen (auto-generated information on the LLVM classes and libraries): http://llvm.org/doxygen/namespaces.html Other documentation can be found at http://llvm.org/docs. -- John T.> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >