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