[LLVMdev] Architecture Dependency of LLVM bitcode (was Re: compile linux kernel)

[Andrew Lenharth]

On Mon, Sep 29, 2008 at 8:18 AM, Christian Plessl
<christian.plessl at uni-paderborn.de> wrote:
> -  Is the architecture dependence of LLVM IR only an artifact of llvm-
> gcc producing architecture dependent results?

No.
It also is an artifact of code compiling architecture and OS dependent
features based on what they detect at configure time
It is an artifact of compiling non-type safe languages.
It is an artifact of system headers including inline asm.
It is an artifact of the endianness of the system.

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

A better question is: what architecture-abstracting features would
make writing target independent LLVM bitcode easier?  There is 1 that
I think is critical, and 3 more that would make life much easier
(though technically redundant).

hton and ntoh intrinsics.  These are needed to allow target code to
deal with endianness in a target independent way.  (Ok, you could
potentially write code that detected endiannes at runtime and chose
multiversioned code based on that, but that is ugly and optimization
prohibiting).

redundant, but greatly simplifying:

iptr aliased type.  There are legitamate cases where you want to
perform arithmetic and comparisons on pointers that the semantics of
GEP make illegal so the only way to do so in a target independent way
is to either cast to an int you hope is >= than any pointer, or
violate the GEP semantics (which is generally works).

GBP instruction (GetBasePointer).  The inverse of a GEP.  A GEP
selects an offset into a object in a target independent way based on
the type.  What GBP would do would be to get a pointer to the base of
an object based on a pointer to field, a type, and the same specifier
as the GEP would use to get the field.
x == GBP (GEP x, 0, 1, 1), typeof(x), 0, 1, 1
This would make upcasts or any conversion from an embedded object to a
parent object not need arch dependent offsets and raw pointer
manipulation.   (yes you could figure out the offset from GEP off null
trick and use raw pointer manipulation and casts)

sizeof instruction.   Again, you can use the GEP off null trick, but
this isn't very obvious, but since it doesn't involve raw pointer
manipulation.

Andrew