similar to: [LLVMdev] Re:RE: Question about inserting instructions

Hi, I am working on a project with LLVM. What I need to do is to generate/insert some dummy/dead basic blocls which never have chance to be executed and put some instructions in those dummy/dead basic blocks. So far, the dummy/dead BB insertion is done. I am trying insert instructions in those dummy/dead BB. Actually, I can insert the legal instructions to dummy/dead BB, however, I really want

On Wed, May 11, 2005 at 01:30:29PM -0700, Qiuyu Zhang wrote: [snip] > push %eax > das > clc > > all of them are legal one-byte x86 machine instructions. [snip] > If there is a way to be able to get that, I am supposed that like > the following, > > 1. generate some dummy BB on IR level ( working on *.bc by writing a

Ram: Let me explain and hopefully Reid or Chris will correct if I have it wrong. The first 0 is the index into a possible array of sbyte[13] arrays that this pointer points to. I expect GetElementPtr works this way is to keep down the proliferation of arrays of arrays in the type table. So you are pointing at the zeroth, and in this case only, array of sbyte[13]. The next 0 actually

Ram, Please read and understand the GetElementPtr FAQ available here: http://llvm.org/docs/GetElementPtr.html That will help you understand how it works. We wrote that document specifically because this question comes up all the time. Reid. On Sun, 2006-11-12 at 11:13 -0800, Ram Bhamidipaty wrote: > I am trying to understand the hello word assember example. This is > my version: >

I am trying to understand the hello word assember example. This is my version: %str1 = internal constant [13 x sbyte] c"Hello World\0a\00" declare int %printf(sbyte*, ...) implementation ; Functions: int %main() { %str2 = getelementptr [13 x sbyte]* %str1, long 0, long 0 call int(sbyte*, ...) *%printf(sbyte* %str2) ret int 0 } Why is getelementptr being given two "long

Hi, I must say I also was in need of this document but never knew it existed. It seems to be linked from the faq page only. I only read that the first day I came to LLVM. Maybe linking it from the GetElementPtr instruction in LangRef.html would make sense. cheers Eric On Nov 12, 2006, at 8:47 PM, Reid Spencer wrote: > Ram, > > Please read and understand the GetElementPtr FAQ

On Mon, 13 Nov 2006, Eric van Riet Paap wrote: > I must say I also was in need of this document but never knew it > existed. It seems to be linked from the faq page only. I only read > that the first day I came to LLVM. Maybe linking it from the > GetElementPtr instruction in LangRef.html would make sense. That makes a tremendous amount of sense to me! -Chris > On Nov 12, 2006,

When I increased COLS to the point where the loop could no longer be unrolled, the selection dag code generator generated effectively the same code as the default X86 code generator. Lots of redundant imul/movl/addl sequences. It can't clean it up either. Only unrolling all nested loops permits it to be optimized away, regardless of code generator. Jeff Cohen wrote: > I noticed

On Nov 13, 2006, at 9:01 AM, Reid Spencer wrote: > On Mon, 2006-11-13 at 01:10 -0800, Chris Lattner wrote: >> On Mon, 13 Nov 2006, Eric van Riet Paap wrote: >>> I must say I also was in need of this document but never knew it >>> existed. It seems to be linked from the faq page only. I only read >>> that the first day I came to LLVM. Maybe linking it from the

On Mon, 2006-11-13 at 01:10 -0800, Chris Lattner wrote: > On Mon, 13 Nov 2006, Eric van Riet Paap wrote: > > I must say I also was in need of this document but never knew it > > existed. It seems to be linked from the faq page only. I only read > > that the first day I came to LLVM. Maybe linking it from the > > GetElementPtr instruction in LangRef.html would make sense.

I noticed that fourinarow is one of the programs in which LLVM is much slower than GCC, so I decided to take a look and see why that is so. The program has many loops that look like this: #define ROWS 6 #define COLS 7 void init_board(char b[COLS][ROWS+1]) { int i,j; for (i=0;i<COLS;i++) for (j=0;j<ROWS;j++) b[i][j]='.';

Chris Lattner wrote: > > And why isn't it possible to just make those functions known to LLVM? > > After all, *I think*, if this function is to be called, it should be > > declared in assembler, and so you have to pass some information abou > > those function to the code printer. (Of course, it's possible to just > > directly print the declarations, but

Thanks! Problem is though, that the Ruby compiler is integrated in the compilation of the program being executed, to be able to parse & compile dynamic code at run-time. Therefore the calls to ExecutionEngine::getPointerToGlobal(F) need to be made in LLVM code. Here is a detailed simplistic example in pseudocode of what we want to do: First Ruby code is entered at run-time, received as a

Ok, I got home so I have more details. Here's the sample C program: ----------------- C program --------------- #include <stdio.h> int main() { printf("hello world\n"); return 0; } ------------- end C program ------------- This is compiled using llvm online demo into the following llvm code (target removed): ----------------- LLVM code -------------- deplibs

On Mon, 7 Mar 2005, Vyacheslav Akhmechet wrote: > Ok, I just tried the patch with some modifications (added msvc target > and used WIN32 instead of __MINGW32__ for preprocessor) and everything > worked beautifully. Thanks for the help! Did you actually try the previous patch? If you compiled llvm-gcc with mingw, it should work, regardless of the compiler you use to compile the LLVM

My first patch was a little premature, please use this one. On Mon, 2005-03-07 at 17:19, Reid Spencer wrote: > Vyacheslav, > > This is the same problem that I had with Cygwin .. nearly identical. > The issue was documented in PR492 if you want some background. I'm > currently trying to dig up what I did to fix this in December for Cygwin > and see if I can apply the same

Yes, but it won't work in the future because the VC++ build will use Intel syntax, not AT&T. If you have mingw installed, why not use it to build LLVM? It's a lot more functional. Mixing and matching Microsoft and GNU tool chains is not good for your sanity. Vyacheslav Akhmechet wrote: >Reid, > >This patch won't work for me. I compile llvm toolset with MSVC Express

Ok, I just tried the patch with some modifications (added msvc target and used WIN32 instead of __MINGW32__ for preprocessor) and everything worked beautifully. Thanks for the help! On Mon, 7 Mar 2005 20:45:40 -0500, Vyacheslav Akhmechet <coffeemug at gmail.com> wrote: > Reid, > > This patch won't work for me. I compile llvm toolset with MSVC Express > (hence __MINGW32__

Vyacheslav, This is the same problem that I had with Cygwin .. nearly identical. The issue was documented in PR492 if you want some background. I'm currently trying to dig up what I did to fix this in December for Cygwin and see if I can apply the same change for mingw. Reid. On Mon, 2005-03-07 at 16:39, Vyacheslav Akhmechet wrote: > Ok, I got home so I have more details. Here's the

Reid, This patch won't work for me. I compile llvm toolset with MSVC Express (hence __MINGW32__ won't be defined for me at compile time). I only try to feed the generated assembly into gcc (pretty much gnu assembler, I suppose). I don't use mingw tools at the earlier stage. However it's obvious for me how to modify the code now (just add MSVC at that line), thanks! I'll try it