search for: i_getelementptr

Hi all, I'm reading the language reference of LLVM here: http://llvm.org/docs/LangRef.html#i_getelementptr In the first example, it shows that the generated IR is supposed to be something like: %reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13 But when I copied the code and compile it myself (using v2.7), I got five getelementptr instructions, which are just like the equivalent code give...

Hello, I'm trying to write an annotation pass which will pass a C function a number of parameters including one of type [16 x i8*]. However, when I write the C function, this parameter type is compiled to type i8** because of the semantics of arrays in C. I think that to convert this parameter to i8**, I would need to take the address of the array. Is there any way I can do this? If

Patrick Simmons <simmon12 at illinois.edu> writes: [snip] > Is there any way I can do this? If not, is there any way for me to > accomplish what I want here? http://www.llvm.org/docs/LangRef.html#i_getelementptr

...x sbyte]* %tmp.0 to %struct.array* This is almost exactly what you want to do. Please make the array be [0 x int] though, as it is undefined in llvm to access past the end of an array with non-zero length. I added a note about zero-length arrays here: http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr http://llvm.cs.uiuc.edu/docs/LangRef.html#t_array > It is clear what happens here, but I don't know how I would reproduce that, > because I can't easily find out the length in bytes of the array. I'm not sure I understand. Are you saying that, at runtime, you need ot know the...

...CVS, structure indices are required to be 'uint' constants, which permits structures with up to 2^32 elements. Sequential type indices are allowed to be any int, uint, long, and ulong values. This is documented in the LLVM language reference here: http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr This change required modifying the encoding of getelementptr instruction in bytecode files, so LLVM 1.3 bytecode files won't be readable by LLVM 1.2 and earlier. LLVM .ll files and .bc files from earlier releases, as usual, will work fine with the newer version. In particular, we will always...

...elements of Elts will be indistinguishable. I'm not following; are you trying to access the first member of NewSTy here? You can't use a type that hasn't been created yet. You might be able to pull some tricks with incomplete types or casts, though. http://llvm.org/docs/LangRef.html#i_getelementptr and http://llvm.org/docs/GetElementPtr.html might be useful here. > Elts.push_back(Type::Int32Ty); > StructType *NewSTy = StructType::get(Elts); > > Presumably at this point is is definitely possible to declare variables > of type NewsTy and use field-selectors from NewSTy. B...

...es are required to be 'uint' constants, which > permits structures with up to 2^32 elements. Sequential type indices are > allowed to be any int, uint, long, and ulong values. This is documented > in the LLVM language reference here: > http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr > > This change required modifying the encoding of getelementptr instruction > in bytecode files, so LLVM 1.3 bytecode files won't be readable by LLVM > 1.2 and earlier. LLVM .ll files and .bc files from earlier releases, as > usual, will work fine with the newer version. In p...

Hi LLVM-dev! I'm having problems figuring out how to do variable sized structs in LLVM (which are neccessary for PyPy's LLVM backend, on which I'm working). I'm trying to do the equivalent of struct array { long refcount; long length; long items[1]; }; in LLVM, where the items array can be arbitrarily long. I guess that the struct definition should

I'd like to be able to make use of a structure type and its fields before it is completely defined. To be specific, let me ask detailed questions at various stages in the construction of a recursive type. I copy from http://llvm.org/docs/ProgrammersManual.html#TypeResolve // Create the initial outer struct PATypeHolder StructTy = OpaqueType::get(); Is it possible to declare

...r_, which is often forgotten about. This allows LLVM to translate this C code: int *P = ... P = P + 1; into this LLVM code: %P.1 = ... %P.2 = getelementptr int* %P.1, long 1 This probably won't make sense the first time you see it. Take a look at: http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr And remember that we are turning the '->' syntactic sugar into it's equivalent [0] form. If you have any other questions about this, please just let me know (and try out the fixed verifier too :) -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/

....compilers.llvm.devel as well. > > Patrick Simmons <simmon12 at illinois.edu> writes: > > [snip] > >> Is there any way I can do this? If not, is there any way for me to >> accomplish what I want here? >> > > http://www.llvm.org/docs/LangRef.html#i_getelementptr >

> This is almost exactly what you want to do. Please make the array be [0 x > int] though, as it is undefined in llvm to access past the end of an array > with non-zero length. I added a note about zero-length arrays here: > > http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr > http://llvm.cs.uiuc.edu/docs/LangRef.html#t_array > > As you mention above, you should use malloc and cast the return value. If > you want to get the desired size in a target-independent way (always > good), you should do something like this: > > %array = type { int, int,...

.... :( > so -- what exactly does the first indexing uint 0 do? is it safe to leave > it off? do all good getelementptrs have it, so that i should assert that > there is one? The LLVM language ref gives a decent example of what it's used for: http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr For this MP though, you really don't need to understand it. Basically if the first index is NOT a long 0, some array stuff is going on, and your pass cannot handle it anyway. Your safety checker should consider any allocas used this way (as in any allocas with non-long 0 first indexes) as no...

While it is great that LLVM has an IR Verifier, its a little troublesome to use because it separates the point of detection from the source of the problem. That is, the verifier gets run on a module or function after its been built. By that point, the compiler's state has moved past the point at which the error was placed into the module or function. Trying to track down the source of the

By request, I've renamed lib/CodeGen/PreSelection to lib/CodeGen/PreOpts (admittedly this was my choice :-), and the corresponding archive from preselect to preopt. If you see linker errors saying preselect.o is not found, this is the reason. This shouldn't happen if you update your entire tree at once. --Vikram

Hi Misha, Thanks for your answer I was doing this: ======================== BasicBlock *BBlock = new BasicBlock("entry", MyFunc); ... Value *Zero = ConstantSInt::get(Type::IntTy, 0); Value *UZero = ConstantUInt::get(Type::UIntTy, 0); MallocInst* mi = new MallocInst( STyStru ); mi->setName("tmp.0"); BBlock->getInstList().push_back( mi );

...e 'uint' constants, which > > permits structures with up to 2^32 elements. Sequential type indices are > > allowed to be any int, uint, long, and ulong values. This is documented > > in the LLVM language reference here: > > http://llvm.cs.uiuc.edu/docs/LangRef.html#i_getelementptr > > > > This change required modifying the encoding of getelementptr instruction > > in bytecode files, so LLVM 1.3 bytecode files won't be readable by LLVM > > 1.2 and earlier. LLVM .ll files and .bc files from earlier releases, as > > usual, will work fine with...

...wn semantics is after the syntax has been constructed, not before. If it's possible to do some of it statically during parse tree construction, that's fine, but it shouldn't be *required*. But it's evidently not the way llvm thinks. > > http://llvm.org/docs/LangRef.html#i_getelementptr and > http://llvm.org/docs/GetElementPtr.html might be useful here. These operations also require a completed tyle. > >> Elts.push_back(Type::Int32Ty); >> StructType *NewSTy = StructType::get(Elts); >> >> Presumably at this point is is definitely possible to d...