[LLVMdev] Lowering x64bit LLVM IR to x86bit LLVM IR

[Tim Northover]

Hi Sandeep,

On 4 December 2014 at 19:47, Sandeep Kumar Singh <deepdondo007 at gmail.com> wrote:
> As per my requirement, I am trying to lower down the x86_64bit binary LLVM
> IR to x86 LLVM IR.
> Instruction of x86_64 binary are as follows,
> mov rax, 1122334455667788
> mov rax, 8877665544332211
> To lower down the same in x86, I need to split 'rax' register into
> 'rax_lower' and 'rax_higher'.

If you just want *some* code, then LLVM can take care of this itself.
You just have to compile the IR for a x86 target: "llc -mtriple=i686
..." or similar.

For example if you compile

    define i64 @foo() {
      ret i64 1122334455667788
    }

to i686, you get:

    foo:
        movl $-628319156, %eax       # imm = 0xFFFFFFFFDA8C9C4C
        movl $261313, %edx           # imm = 0x3FCC1
        retl

where the value obviously gets returned in eax & edx.

On the other hand, if you want the result to be compatible with real
x86 code, or even itself, you've probably got an impossible task. A
few of the big problems are:

1. Because of the differing alignment requirements struct layout will
be completely different. Code is allowed to rely on that ("malloc(N *
sizeof(type))" is a common C idiom that would break irretrievably).
2. The va_arg implementation is completely incompatible between the
two, and implemented entirely by Clang on x86_64. Varargs functions
won't work even if all code is compiled in this odd x86_64 -> x86 way.
3. The actual types used in parameter passing are different based on
the target (at least, they are on other platforms). Clang needs to
know the destination ABI to get this right and reconstructing the
intent would likely not be possible (I can't say for sure since I
haven't studied the x86 ABIs).

It all comes down to the fact that LLVM IR isn't target independent.
Clang has to know quite a lot of individual platform details to emit
its code, and they're pretty much baked in.

The PNaCl project is an effort to make a common subset work across
multiple platforms. Have you looked into whether that would fit your
needs? The output won't be compatible with the usual platform
libraries, but will with its own runtime.

Cheers.

Tim.