[LLVMdev] Preferring to use GCC instead of LLVM

Óscar Fuentes ofv at wanadoo.es
Sun May 11 10:38:22 PDT 2008


Owen Anderson <resistor at mac.com> writes:

>>> That's only a convenience. 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.
>>
>> 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.
>>
>
> Actually, I think Bill's right on target.  The OP was implying that
> LLVM is incomplete because it depends on GCC in the backend, which is
> incorrect.  It depends on binutils, _which GCC also depends on_.  Thus
> LLVM is certainly no less complete than GCC in that sense.

There is a culture schism here. The Windows folks are accustomed to
monolithic packages that does all the work. For Unix folks, having
"tool-chains" is the natural way. 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.

The OP talks about GCC because that's what he sees, irrespectively of
the other tools behind. In Windows, installing GCC implies installing
binutils, either via MinGW or Cygwin. This is deeply rooted into the
Windows development culture: a "compiler" has all needed parts for
creating an executable. They talk about the Visual C++ compiler, or the
Borland compiler, never about the Borland compiler and linker.

> 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.  GCC,
> the primary alternative, also depends on these things, so having them
> would be a competitive advantage, not a requirement for parity.

Absolutely agreed. I'm just trying to explain from where the OP (seems
to) come.

>>> "Microsoft Assembler":
>>>
>>> http://www.microsoft.com/downloads/details.aspx?FamilyID=7a1c9da0-0510-44a2-b042-7ef370530c64&displaylang=en
>>
>> This does not *comes* with MS Windows. It is a separate download,
>> which
>> depends on more downloads (Visual C++ Express Edition) and is for
>> non-commercial use only. Furthermore, you can't re-distribute it.
>>
>
> From what I read, it's 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.

Exactly. And this is very different from the GNU/Linux and BSD case,
where the existence of a compiler, assembler and linker along the OS is
considered a "reasonable requirement" and part of the standard
installation in most cases. 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. (Leaving aside the fact that a compiler backend is not required to
generate executable files, but his insistence on this point is related
to the "monolithic package" paradigm I mentioned above).

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

Sure. And, AFAIK, even if you want to use MASM, you need to add support
for his assembler format to LLVM.

> And in those environments, the competition is, once again, GCC, which
> still depends on gas and ld.
>
> The fundamental problem is that both executable formats and linking
> problems are EXTREMELY platform specific,
[snip]

Agreed. I'm just trying to explain that, from the POV of the OP's
culture, the demands he expressed are quite reasonable. This narrow view
of the world and being... ummmh... too demanding, are the only problems
with the OP message :-)

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

-- 
Oscar



More information about the llvm-dev mailing list