[LLVMdev] Architecture Dependency of LLVM bitcode

Chris Lattner clattner at apple.com
Mon Sep 29 14:19:09 PDT 2008


On Sep 29, 2008, at 6:18 AM, Christian Plessl wrote:
> On 29.09.2008, at 11:53, Jonathan S. Shapiro wrote:
>> Watching this thread, it occurs to me that the "V" in "LLVM" is
>> creating
>> confusion. So far as I know, LLVM is the first project to use
>> "virtual"
>> to refer to the instruction set of the intermediate form. I  
>> understand
>> why this labeling made sense (sort of), but it was unfortunate. The
>> machine is abstract, not virtual, and the use of "virtual" here is so
>> out of keeping with any other use of the term that it really does
>> generate confusion.
>
> The topic whether LLVM bitcode is independent of the target platform
> was raised several times on the mailing list,

Wow, there is a lot of FUD and misinformation on this thread.

> but it was never
> discussed in detail. I would appreciate learning more about the
> following questions:
>
> -  Is the architecture dependence of LLVM IR only an artifact of llvm-
> gcc producing architecture dependent results?

No, it inherent to any C compiler.  The preprocessor introduces target  
specific details and things just go downhill from there:
http://llvm.org/docs/tutorial/LangImpl8.html#targetindep

If you start from a target-independent *language*, you can generate  
target independent LLVM IR.

> - What architecture-specific features are present in the IR that
> prevent running the same LLVM bitcode on different architectures?

Many things are target independent, but the most significant is that  
LLVM allows unrestricted pointer casting.  An example that allows the  
programmer to "see" the underlying endianness of the target is C code  
like this:

int X = ...
char C = *(char*)&X

A language that is target independent (java, perl, ...) would not  
allow the programmer to express such things.

>> Is this worth a FAQ entry?
>
> I would definitely appreciate such a FAQ entry.

Patches welcome :)

-Chris



More information about the llvm-dev mailing list