Looking into LLVM

Jeff Garzik jgarzik at pobox.com
Wed Oct 28 11:44:35 UTC 2009


On 10/28/2009 06:24 AM, Kevin Kofler wrote:
> Jud Craft wrote:
>
>> On Mon, Oct 26, 2009 at 12:31 PM, Kevin Kofler wrote:
>>> But this is about C++.
>>
>> I don't mean to misunderstand, but if I recall from your very first
>> post in this thread...
>>
>>> Actually, the ABI issue is only if you use the C code generator, not the
>>> native ones.
>>
>> Hence I thought you were talking about ABI issues with C.
>
> You misunderstood me. The C code generator is an LLVM *back*end, not a
> frontend. The frontend is what recognizes the input language, the backend is
> what defines the output LLVM generates.
>
>> I'm not up on how LLVM frontend integration works, so I actually don't
>> understand the distinction between "the LLVM C Backend" and "the
>> native LLVM backends".
>
> LLVM can either directly output machine code (native backend) for some
> architectures or it can output preoptimized C code (especially for those
> architectures which don't have a native backend). The latter is what the "C
> code generator" or "C backend" does.

clang and all other LLVM language front-ends produce "bitcode", which is 
virtualized machine code a la JVM.  LLVM backend generates 
processor-dependent machine code from processor-independent machine code.

The LLVM C __backend__ converts bitcode back into C...   something no 
idiot in their right mind would use for C++ or anything else.  The LLVM 
C backend is not commonly used.

The vast, vast majority of people trying to compile C++ programs with 
LLVM would either use
	clang -> llvm -> asm code
		or
	llvm-gcc -> llvm -> asm code

Certainly not
	Clang (C++) → LLVM → LLVM C backend → gcc [-> asm code]

Regards,

	Jeff






More information about the fedora-devel-list mailing list