llvm dev - Dec 2014 - [LLVMdev] Lowering x64bit LLVM IR to x86bit LLVM IR

Hi,

I need some help,
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'.
Can anybody please give me some pointer to do the same or any tool with
option to generate the
same type of LLVM IR.

Any help will be highly appreciated.

Thanks and Regards,
Deep
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141205/4b20fb29/attachment.html>

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.

Hi Tim,

Thank you for this information.
I have another request for help from you,
Below is my test case,
iGetValueFromASM proc
mov rax, 5
mov rax, 5
mov rax, 2
mov rax, 5
mov rax, 2
mov rax, 112233445566
add rax, 2
mov rax, 112233445566
add rax, 5
add rax, 2

I have lowered 32bit LLVM IR,
%0 = type { i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32,
i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32,
i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32, i32 }

define i32 @"iGetValueFromASM@#@1400037b0"(%0*) {
  %2 = getelementptr inbounds %0* %0, i32 0, i32 0
  %3 = getelementptr inbounds %0* %0, i32 0, i32 1
  %4 = getelementptr inbounds %0* %0, i32 0, i32 21
  %5 = load i32* %4, align 4
  %6 = getelementptr inbounds %0* %0, i32 0, i32 24
  %7 = load i32* %6, align 4
  %8 = and i32 %7, -2262
  %9 = add i32 %5, 14323
  store i32 564295877, i32* %2, align 4
  store i32 26, i32* %3, align 4
  store i32 %8, i32* %6, align 4
  ret i32 %9
}

This is generated with my are written. Now, I want to test this generated,
lowered x64bit IR for x86bit machine.
Please let me know how I can test this. How I can test generated LLVM IR,
how I can debug this generated LLVM IR.

Any help will be highly appreciated.

Regards,
Deep

On Fri, Dec 5, 2014 at 8:25 PM, Tim Northover <t.p.northover at gmail.com>
wrote:
>
> 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.
>

-- 

Thanks and Regards,
Sandeep Kumar Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/2f608c8e/attachment.html>