[LLVMdev] Preferring to use GCC instead of LLVM

[kr512]

Jon Harrop wrote:
> Can you explain why you would like to generate DLLs on the 
> customer's computer rather than using LLVM as a JIT 
> compiler?

Customers/clients unhappy with the inefficiency, extra CPU 
and RAM usage, and performance penalty of JIT.  They require 
a faster, more efficient solution.  The solution is to fully 
compile programs to native code at the time of installation 
of programs on customer's computer, instead of incurring JIT 
overhead every time the program is launched and run by 
customer.

A customer installs a program once (or rarely), but 
launches/runs it many times.  Customers don't care if 
program installation (including compiling to native code) is 
a bit slow, because they do it only once.  But they DO care 
if launching and/or running the program is slow or 
inefficient, because they do this very often.

Customers/clients demand that cost of converting to native 
code be shifted out of run-time, and into installation-time 
instead.

Major client says using JIT is "a moronic strategy with 
unnecessary complexity and undesirable performance (CPU and 
RAM use) characteristics, with significant disadvantages 
compared to fully converting programs to native code at time 
of installation".

Nick Lewycky wrote:
> Although we can emit the opcodes in binary form, support 
> for the container formats isn't working properly. Thus 
> far, there's an unfinished ELFWriter and MachOWriter in 
> lib/Codegen/. Those could be finished, and PEWriter could 
> be added for Win32 support.

It would be wonderful if support for the 3 container formats 
could be finished/implemented.  It would make LLVM far more 
appealing for use in real-world situations.

> If this is blocking you from using LLVM,

Yes, it is.

> please consider whether it'd be easier to write this for 
> us than to use something else.

Would love to, but unable to do that this year.  Might be 
able to do it this time next year at the earliest.  Also 
would love to throw money at certain LLVM developers, but 
not in a position to do that at the present time, maybe 
later.

Bill Wendling wrote:
> GCC generates assembly code too and calls the assembler 
> and linker as part of it's execution. You are perfectly 
> able to call the assembler & linker yourself.

No, the assembler and linker do not exist on customer's 
computers running Windoze.

Bill Wendling wrote:
> You should really learn how to use Google. Got this as the 
> top hit for "Microsoft Assembler":   [Microsoft Macro 
> Assembler 8.0 (MASM) Package (x86)]

Incorrect.  That webpage says that it requires that 
Microsoft Visual C++ 2005 (Express Edition) be installed on 
the computer before MASM can be installed.

We cannot reasonably require our customers to install 
Microsoft Visual C++, or if we did, then we may as well use 
MS Visual C++ to do everything -- then there is no need for 
LLVM.

Oscar Fuentes wrote:
> This means that LLVM requires an assembler and linker. 
> Call it GCC or binutils, it is irrelevant. The OP point is 
> that LLVM is not a self-sufficient tool on this aspect.

Correct.

Owen Anderson wrote:
> The OP was implying that LLVM is incomplete because it 
> depends on GCC in the backend, which is incorrect.  It 
> depends on binutils,

Alright, so I used the wrong name.  I said GCC but I should 
have said binutils.  My original point remains valid -- LLVM 
is an incomplete backend because by itself it is unable to 
generate a ready-to-execute .EXE or .DLL file.

And binutils is not necessarily available on the customer's 
computer.  Do all Linux and BSD distributions include it 
preinstalled?  Maybe, but what about Windoze and MacOS?  I 
know Windoze does not include it or any equivalent.  And 
Apple's developer tools (Xcode etc) for MacOS X are not 
preinstalled either, they are a separate download (although 
perhaps binutils is preinstalled in MacOS X, not sure, 
haven't checked).

Now, if I am going to require that the customer download and 
install Apple's Xcode package, or Microsoft's C compiler 
tools, then I may as well use them to do everything I need. 
Having them installed eliminates the need for LLVM.   But I 
would prefer to use LLVM, and I certainly don't want to 
require that customers download and install Apple's or 
Microsoft's compiler tools.

Owen Anderson wrote:
> I think the point is that implementing our own linker is 
> definitely beyond the purview of LLVM, and implementing 
> our own object file writer/assembler is honestly pretty 
> low on the priority queue.

That attitude is very much hurting LLVM's popularity and 
adoption in real-world situations.

Owen Anderson wrote:
> From what I read, [MASM is] included with copies of Visual 
> Studio.  I assume that a paid copy of Visual Studio (as 
> opposed to the free Express edition) includes a version 
> that's licensed for commercial use.

Then we may as well use Visual Studio to do everything, and 
not bother with LLVM.  But I prefer to use LLVM if possible.

> Additionally, LLVM's support for Win32 outside of 
> MinGW/Cygwin is ...  spotty at best.

LLVM needs to sever its backend ties with 
MinGW/Cygwin/GCC/binutils.  Because if we are going to use 
the hacked bastard child of LLVM combined with 
MinGW/Cygwin/GCC/binutils, then we may as well just use the 
normal version of MinGW/Cygwin with GCC and not bother with 
the added complication of LLVM.

> The fundamental problem is that both executable formats 
> and linking problems are EXTREMELY platform specific, so 
> it's typically best to leave it up to the system tools.

But these system tools do not exist (or are not installed) 
on all relevant/significant customer computers.

> P.S.  I do agree that, if he has a desperate need to run 
> LLVM outside of MinGW/Cygwin, JIT is his best bet.

JIT is a bad solution, for the reasons I explained above.

Oscar Fuentes wrote:
> For a Windows folk, having extra requirements goes against 
> what he is accustomed to. If LLVM is perceived as a 
> backend, but it fails short into producing the final 
> result, the typical Windows folk will be disappointed.

Yes.  Very much so.

> The OP talks about GCC because that's what he sees, 
> irrespectively of the other tools behind.

Yes, I used the wrong name, but my point is still valid.

Oscar Fuentes wrote:
> If the OP plans to deploy his compiler on Windows, he 
> can't assume the existence of an assembler/linker on most 
> user's machines. He becomes dependent of third-party 
> packages, hence LLVM is not a "complete backend" from his 
> (limited) point of view.

Yes!!  I know you people like Linux and BSD, and I do too, 
but the fact is we have customers using Windoze, and we have 
customers using Linux, and we need to support them both.

To say that we should ditch all our Windoze-using customers 
and only support Linux-using customers, to say that would be 
prejudiced, fanatical, irrational, unrealistic, 
unreasonable, and living in a fantasy dream world detached 
from reality.

> Expect more messages like this as LLVM becomes more 
> popular outside professional and academical circles.

Yes.  But also as LLVM becomes more popular inside 
professional, commercial, and business circles focused on 
delivering real-world practical implementations/solutions.

Chris Lattner wrote:
> FWIW, I wouldn't be surprised if the LLVM project 
> eventually grew more of native toolchain support (e.g. 
> assembler, linker, etc).  It would fit naturally with the 
> growing scope of the project.

Yes, it would, and it would make LLVM more popular and more 
usable in real-world situations.

> I don't think that it is a high priority for anyone 
> though.

Then you are disadvantaging the LLVM project and holding it 
back.  I see you are working on a C front-end "clang". 
Personally I think that a C front-end should be a much lower 
priority than delivering a COMPLETE backend.

Another C compiler is not needed.  GCC and MSVC already do 
that job, and you won't supplant them.  The thing that is 
really needed is in accordance with the essence of LLVM -- a 
complete backend solution.

Emilio Wuerges wrote:
> Is this thread suposed to be a bad joke?

That is a very unprofessional response to my legitimate 
questions and concerns, and my good-faith attempts to ASSIST 
the LLVM project by providing some constructive criticism 
and feedback (and possibly contributions later).

Terence Parr wrote:
> Yeah, i'm kinda freaked out as i'm sure it's not a joke. 
> i'm in awe. +1 to kill thread before google spiders it.

Again, that is a very unprofessional response.

Bill Wendling:
>> OTOH, I'm curious about why the OP needs to produce dlls 
>> on the fly. Isn't the JIT ok?
> I doubt he knows.

Doubt I know?  Another unprofessional response.  I have now 
answered Jon's JIT question in this email.

Chris Lattner wrote:
> If you'd prefer to use GCC, go for it.  No one is forcing 
> you to use LLVM.
> You are seriously ignorant of what LLVM is all about. 
> Please go inform yourself.

That was an unprofessional response as well.