similar to: [LLVMdev] need help understanding getelementptr assembler instruction

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

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, 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.

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: >

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,

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

Hey again) Now I have next code: ; ModuleID = 'sample.lz' @.str1 = internal global [8 x i8] c" world!\00" ; <[8 x i8]*> [#uses=1] @.str2 = internal global [8 x i8] c"hello, \00" ; <[8 x i8]*> [#uses=1] @.str7 = internal global [21 x i8] c"welcome to out hall!\00" ; <[21 x i8]*> [#uses=1] declare i32 @puts(i8*)

Yes, I agree with you -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080106/efb1c465/attachment.html>

but why this code don't work: ; ModuleID = 'sample.lz' @.str1 = internal global [6 x i8] c"world\00" ; <[6 x i8]*> [#uses=1] @.str2 = internal global [7 x i8] c"hello \00" ; <[7 x i8]*> [#uses=1] @.str7 = internal global [7 x i8] c"father\00" ; <[7 x i8]*> [#uses=1] @.str8 = internal global [8 x i8]

Dear developers: When I am doing basicblock pass, I meet a bug: there is an iterator "I" in a basicblock, and it is not pointing to the first instruction in this basicblock. However, "I--;" will fail by an assertion. The basic block ("I" is pointing to the second instruction) in test.ll: bb: ; preds = %bb1 %1 = call i32 (i8*, ...)* @printf(i8* noalias

Hello! I'm having trouble with pointer traversing. I have a design as follows: class -> map -> classFunctions Starting with a pointer to the class, I want to get a pointer to a classFunction via a pointer to the map. I can't get that function pointer! How shall I think to get the traversing right (see code below)? Is it something with the fact that I am using only pointers in my

It's invalid for the same reason that char *foobar = strcat("foo", "bar"); is invalid in C. Please make sure you understand what you're asking LLVM to do before going any further down this path. A good approach is to write out the correct code in C and then use llvm-gcc (or the demo page at http://llvm.org/demo ) to see what it looks like in LLVM assembly. Nick

Hello, I'm having problems with the following LLVM instruction %tmp.0.i = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([11 x sbyte]* %.str_1, long 0, ...... The first argument in function call, sbyte* getelementptr ([11 x sbyte]* %.str_1..... appears to be ConstantExpression*, and my backend does not support ConstantExpression yet. I probable can implement

On Mon, 3 May 2004, Anders Alexandersson wrote: > Hello! > > I'm having trouble with pointer traversing. I have a design as follows: > class -> map -> classFunctions > > Starting with a pointer to the class, I want to get a pointer to a > classFunction via a pointer to the map. Okay... > I can't get that function pointer! > > How shall I think to get

hm.... I think, that is valid in c but next code too doesn't works right: ; ModuleID = 'sample.lz' @.str1 = internal global [6 x i8] c"world\00" ; <[6 x i8]*> [#uses=1] @.str2 = internal global [7 x i8] c"hello \00" ; <[7 x i8]*> [#uses=1] @.str7 = internal global [7 x i8] c"father\00" ; <[7 x i8]*> [#uses=1]

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

I am trying to create such module with API (it's equivalent to c++: const char* ss[] = {"s1","s2"};): @ss = global [2 x i8*] [i8* getelementptr inbounds ([3 x i8]* @.str1, i32 0, i32 0), i8* getelementptr inbounds ([3 x i8]* @.str2, i32 0, i32 0)] ; <[2 x i8*]*> [#uses=0] @.str1 = private constant [3 x i8] c"s1\00", align 1 ; <[3 x i8]*> [#uses=1]

How do I tell the optimizer that the (dereferenced) value of an i8** parameter is NULL at the start so that it can eliminate the check? I have code like: void test2(void** ex) { printf("go\n"); // does not change *ex } void call2(void** ex); void testeh(void** ex) { // I want to tell the optimizer *ex is null so it can eliminate the first

Vyacheslav, I've tracked down the change and I have a fix for you to test. The attached patch should be applied to the CVS head (version 1.132) of X86AsmPrinter.cpp in llvm/lib/Target/X86. The patch just includes MINGW targets in the same set of choices that it makes for Cygwin. Could you please try the patch and let me know if it solves your problem? If it does, I'll commit the patch.

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