Sandeep Kumar Singh
2014-Dec-05 03:47 UTC
[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.
Sandeep Kumar Singh
2014-Dec-18 11:18 UTC
[LLVMdev] Lowering x64bit LLVM IR to x86bit LLVM IR
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>
Apparently Analagous Threads
- [LLVMdev] Lowering x64bit LLVM IR to x86bit LLVM IR
- OpenSolaris for sparc in qemu on linux x64
- [LLVMdev] use of undeclared identifier '__NR_*' error while building clang
- [Error] guestfsd: /usr/lib/libaugeas.so.0: version `AUGEAS_0.16.0' not found (required by guestfsd)
- Unable to create channel of type 'DAHDI' (cause 17 - User busy)