LLVM as a DLL

Project Infrastructure LLVM Dev List Archives
1

Hi there

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:
http://www.sqlite.org/download.html

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.

Mark

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

Apparently the APIs in the LLVM docs missed your attention. They’re sneaky that way because, you know, they just form the bulk of available documentation.

The command-line tools are convenience wrappers around the APIs, not the other way around.

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.

I’m sure the LLVM lead (Chris, was it?) will gratefully accept any such functioning, tested code you can supply that generates the native object format you prefer. This is, after all, how open source projects work for the most part.

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.

So… here’s a thought. Why don’t you do that one-time work and host the compiled package up on a web page somewhere as a service to this open source community that will so eagerly embrace it? You will certainly not be criticized for it and will likely instead have your name sung to the heavens by the myriad of Windows developers who’ve wanted to use LLVM but haven’t had the opportunity because of the barrier of source code distribution.

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.

So… your world doesn’t include “gas” or “nasm” or any other such assembler? You know. The “gas” that GCC itself uses to assemble the .S files? The “nasm” that’s freely available on a bewildering variety of native platforms? That’s a mighty strange world to be living in, pardner.

A back-end that is totally free of GCC is needed.

Again I’m sure that Chris (?) will gladly accept any functioning, tested source that implements this tossed into the pot that is the open source project LLVM.

3

Hi there

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:
SQLite Download Page

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.

Question: have you actually downloaded and built a copy of LLVM? I'm going to guess that the answer is no, because otherwise you would have realized that LLVM is, in fact, already built as a set of libraries. The tools (llc, lli, opt, etc.) are just thin wrappers around these libraries. They're only meant for use by LLVM developers. Client applications are expected to use the LLVM APIs.

For examples of using it programmatically, see LLVM Tutorial: Table of Contents — LLVM 18.0.0git documentation

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.

Not true. Two things are required: an assembler and a linker. GCC uses both behind the scenes (gas and ld). The invocation of GCC in the example docs you cited is purely for convenience. It could equally well be replaced with invocations of gas and ld.

As a side note, there IS an assembler included with the MS toolset: MASM. It's called ml.exe in recent versions, or ml64.exe for the 64-bit variant. I have no idea if we currently generate MASM-syntax assembly.

--Owen