search for: disassebl

I am writing a transformation that needs to add a call to a function F() at the beginning of main() with the addresses of argc and argv as parameters to F(). However, the bytecode file I'm transforming has not allocated space on the stack for argc and argv. So, I developed my transformation to change main() from: ----- int main(int %argc, sbyte** %argv){ entry: ... // some use of

...ude <stdio.h> #include <stdlib.h> int v1[10000]; int main() { int i; for (i = 0; i < 10000; i++) { v1[i] = i; } for (i = 0; i < 10000; i++) { printf("%d ", v1[i]); } return 0; } Next, I disasseble the executable file and have not found any SSE instructions. I know that LLVM support SSE. So my questions: 1. It is occur only in my computer? 2. If it is not only my bug, then there are not SSE optimizations in LLVM? 3. Have anyone, already worked on this problem? -- Serg Anohovsky. -----...

Hello, Ryan. > It seems as though, when the bytecode is disassebled, the result of the > allocas should be given as a parameter to the stores. It's given. > If the disassembler doesn't give the allocas a name, then that dependency is > not conveyed. Both disassembly & bytecode is correct. Please carefully read LLVM Language reference abou...

...v1[i] = v1[i] * v1[i]" Then, you could use SSE (or any other vector instruction set) to get a substantial speed improvement. > for (i = 0; i < 10000; i++) { > printf("%d ", v1[i]); > } > > return 0; > } > > Next, I disasseble the executable file and have not found any SSE > instructions. > I know that LLVM support SSE. > So my questions: > 1. It is occur only in my computer? > 2. If it is not only my bug, then there are not SSE optimizations in > LLVM? > 3. Have anyone, already worked on this...

...tain about protability as it does dup2 tricks to dump to stdout * --list-module-functions tests basic iteration over stuff in module implemented in patch, want to extend it to iterate over instructions too * --list-module-globals ditto * --disassemble Test llvm-c/Disassebler.h. Not sure about input format, lines of cpu name + hexdumped asm maybe is easiest for FileCheck * --objdump Test llvm-c/Object.h. List sections and symbols of an object file. * --list-targets LLVMGetFirstTarget/LLVMGetNextTarget and whatever can be extracted fro...

...*(&ltmp_3355_85) = ltmp_75_3; *(&ltmp_3356_105) = ltmp_76_9; initLogging((&ltmp_3355_85), (&ltmp_3356_105), 1, 0); ----- The C code is what I intended. That leaves me to believe that my transformation produced the correct bytecode, but the dissassembler is not properly disassebling the bytecode. Ryan Ryan M. Lefever wrote: > I am writing a transformation that needs to add a call to a function F() > at the beginning of main() with the addresses of argc and argv as > parameters to F(). However, the bytecode file I'm transforming has not > allocated spa...

> Why isn't llvm giving a name to the value returned by the allocas and > using it in the store instructions? Because you pass in an empty string for the name in the new AllocaInst calls below. Replace the empty strings with "argc_addr" or whatever you want. > AllocaInst* argc_alloca = new AllocaInst(argc->getType(), "", >

AKA, the Unified Kernel Project, out of China! This patches the linux kernel to provide windows kernel-level services in parallel to linux services and patches wine to use these rather than emulate them. Anyone used, had success with this? Worthwhile? Patching kernels, while not for all newbies, is fairly quick and hopefully painless, at least in Debian. Patching wine is a big job. Since any

...o dump to stdout > > * --list-module-functions > tests basic iteration over stuff in module > implemented in patch, want to extend it to iterate over > instructions too > > * --list-module-globals > ditto > > * --disassemble > Test llvm-c/Disassebler.h. Not sure about input format, > lines of cpu name + hexdumped asm maybe is easiest for FileCheck > > * --objdump > Test llvm-c/Object.h. List sections and symbols of an object file. > > * --list-targets > LLVMGetFirstTarget/LLVMGetNextTarget and whatever ca...

I like the idea, but I find the name confusing; I think it should have `llvm-c` or `c-api` somewhere in the name. This could also serve as a simple example of using the API. -- Sean Silva On Mon, Sep 23, 2013 at 4:00 PM, Anders Waldenborg <anders at 0x63.nu> wrote: > Moving this to llvmdev. > > On Fri, Sep 20, 2013 at 08:26:41AM +0200, Anders Waldenborg wrote: > > >

...every time through the loop, adding <4,4,4,4> as > you go. > > -Chris > > > >> for (i = 0; i < 10000; i++) { >> printf("%d ", v1[i]); >> } >> >> return 0; >> } >> >> Next, I disasseble the executable file and have not found any SSE >> instructions. >> I know that LLVM support SSE. >> So my questions: >> 1. It is occur only in my computer? >> 2. If it is not only my bug, then there are not SSE optimizations in >> LLVM? >> 3. Have an...

Moving this to llvmdev. On Fri, Sep 20, 2013 at 08:26:41AM +0200, Anders Waldenborg wrote: > > > This avoids warnings when included in a application that > > > uses -Wstrict-prototypes. > > > > > > > Should we enable this warning in CFLAGS for LLVM builds to catch this > > sooner? > > It is a C-only warning, and AFAICS there is no C code in