search for: ispack

...of Global Variable, current front-end makes an temporary StructType for initializer as unnamed struct ("%42"). In this case, Is temporary StructType for initializer Unnamed sturct (named structs with no names)? And will be key(StructValType) of StructTypes(map) the number of elements and isPacked in current IR plus a name? (if so, isPacked is likely to be redundant in some types.) Thanks, Jin-Gu Kang _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...thoughts: +++ b/include/llvm/Bitcode/LLVMBitCodes.h @@ -110,10 +110,12 @@ namespace bitc { TYPE_CODE_METADATA = 16, // METADATA TYPE_CODE_X86_MMX = 17, // X86 MMX + + TYPE_CODE_HALF = 18, // IEEE HALF (16-bit fp) - TYPE_CODE_STRUCT_ANON = 18, // STRUCT_ANON: [ispacked, eltty x N] - TYPE_CODE_STRUCT_NAME = 19, // STRUCT_NAME: [strchr x N] - TYPE_CODE_STRUCT_NAMED = 20 // STRUCT_NAMED: [ispacked, eltty x N] + TYPE_CODE_STRUCT_ANON = 19, // STRUCT_ANON: [ispacked, eltty x N] + TYPE_CODE_STRUCT_NAME = 20, // STRUCT_NAME: [strchr x N] + TYPE_CODE_STR...

...bit in. @@ -196,10 +200,12 @@ public: // Methods for support type inquiry through isa, cast, and dyn_cast: static inline bool classof(const StructType *T) { return true; } static inline bool classof(const Type *T) { return T->getTypeID() == StructTyID; } + + virtual bool isPacked() const { return packed; } This doesn't need to be virtual. --- lib/VMCore/AsmWriter.cpp 6 Dec 2006 06:40:49 -0000 1.226 +++ lib/VMCore/AsmWriter.cpp 6 Dec 2006 18:03:06 -0000 @@ -286,18 +286,22 @@ static void calcTypeName(const Type *Ty, Result += ")"; break; }...

Currently, Structure layout is left to targets, which implement them according to the ABI of that platform. While this is fine for most structures, it makes packed structures very ugly. All fields in a packed type must be converted to byte arrays with casts to access fields, which bloats accesses and obsfucates the types. First class support for packed types would clean up the generated code

...e would make more sense > than adding first-class support for a *discriminated* union. > So, I spent a little bit of time looking at how to code this. Rather than defining a brand-new LLVM type, I think the best approach is to generalize the existing StructType. We can change the "isPacked" flag (which is stored in the SubclassData of the type) to a 3-valued enum called StructLayout, which has 3 members: UnpackedLayout, PackedLayout, and UnionLayout. After that, it's mostly a case of hunting down everywhere that calls "isPacked", and adding the appropriate c...

...r for whether the struct should be packed or not, which defaults to not packed. This is strikingly error prone. We even list struct and packed struct as two different types in the LangRef. We don't need to go so far as to offer separate ConstantStruct and ConstantPackedStruct but maybe the isPacked parameter should at least be mandatory? Any objections? Nick

On Jul 12, 2011, at 5:04 AM, Vitaly Lugovskiy wrote: > Hi Chris, > > What's a new way of building recursive types (with C bindings), once > RefineType had been removed? And what's an exact reason for getting > rid of the opaque types - I could not find a relevant discussion in a > mailing list. Hi Vitaly, I didn't add this API, because I'm not very familiar

...ing and value combination for the initializer by themselves. Is there any way to create the struct more simply like this: fields.push_back(Type::getIntNTy(context, 1)); fields.push_back(Type::getIntNTy(context, 2)); fields.push_back(Type::getIntNTy(context, 64)); structTy.setBody(fields, false /* isPacked*/); It's really tough to do layout work and it's very likely to cause bugs. Combining the values for the initializer is also not easy. As my understanding, if I tell llvm API that the struct is not packed, it should handle padding automatically, right? Any comments? Any pointer to refe...

...er I add the body, isOpaque() == false, but isSized() is still false. If I create a StructType using StructType * StructType ::create(LLVMContext &Context, ArrayRef<Type*> Elements, StringRef Name, bool isPacked = false); Then isOpaque() == false and isSized() == true. Can I not make a sized struct starting with an opaque one and adding a body later? -- Rick

Several people have been proding me to write up my thoughts on how to fix the IR type system for LLVM 3.0. Here are some (fairly stream of conscious) thoughts on the matter: http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt Comments welcome! -Chris

...>> than adding first-class support for a *discriminated* union. >> > So, I spent a little bit of time looking at how to code this. Rather > than defining a brand-new LLVM type, I think the best approach is to > generalize the existing StructType. We can change the "isPacked" flag > (which is stored in the SubclassData of the type) to a 3-valued enum > called StructLayout, which has 3 members: UnpackedLayout, PackedLayout, > and UnionLayout. > > After that, it's mostly a case of hunting down everywhere that calls > "isPacked"...

...ge it so that the GC only sees pointers, then I'm dead in the water. As far as my suggestion of marking types go, you are right, it doesn't make sense for most types. It really only matters for structs and pointers. Imagine if structs had an "isRoot" flag that lived next to "isPacked", which makes the struct a distinct type. This would be written in IR as "gcroot { i1, float }" or something like that. The presence of this flag has the same effect as marking a pointer in the GC address space. Combine that with the ability to mark SSA values as roots, and my life...

...m having a size). Ciao, Duncan. > > If I create a StructType using > > StructType * StructType ::create(LLVMContext &Context, > ArrayRef<Type*> Elements, > StringRef Name, > bool isPacked = false); > > Then isOpaque() == false and isSized() == true. > > Can I not make a sized struct starting with an opaque one and adding a body later? >

...aining only that type have the same alignment requirements?  That is, in C-syntax: float* array; struct point { float x; float y; } point p; array = (float*)&p; Does `array[0]` now refer to x, and `array[1]` to y? I'm creating these structures in LLVM with default packing (StructType::isPacked == false). I have a library that takes simple arrays for point structs (OpenGL) and would like to layer nicer types on top. I'm reasonably certain the above holds true, but want to double-check that it's guaranteed. I'd also be doing this type of operation to refer to a list of point...

...need a way to get an access on the class struct field part. I see something like: std::vector<const Type*>StructTy_struct_mydsp_fields; StructTy_struct_mydsp_fields.push_back(StructTy_struct_dsp); StructType* StructTy_struct_mydsp = StructType::get (StructTy_struct_mydsp_fields, /*isPacked=*/false); mod->addTypeName("struct.mydsp", StructTy_struct_mydsp); in the generated llvm2cpp code, i guess it is possible then to iterate through the cloned code looking for the object with "struct.mydsp" name and get the associated field struct so that to later d...

On Dec 30, 2008, at 12:41 PM, Talin wrote: > I've been thinking about how to represent unions or "disjoint types" > in LLVM IR. At the moment, the only way I know to achieve this right > now is to create a struct that is as large as the largest type in > the union and then bitcast it to access the fields contained within. > However, that requires that the

Hi, I want to add an integer field to all C++ classes in LLVM. Where do I look at in the LLVM source to make the necessary changes? As of now, what I understand is that I need to make changes in Type.cpp (llvm/lib/IR/Type.cpp) where I insert an integer field in the ArrayRef passed to StructType::setBody? Thanks! -Mohit. -------------- next part -------------- An HTML attachment was scrubbed...

On Mon, Mar 7, 2011 at 12:48 PM, Talin <viridia at gmail.com> wrote: > On Mon, Mar 7, 2011 at 10:58 AM, Joshua Warner <joshuawarner32 at gmail.com>wrote: > >> Hi Talin, >> >> Sorry to interject - >> >> >>> For example, suppose I have a type "String or (float, float, float)" - >>> that is, a union of a string and a

...the water" - because it could be made to work. > > As far as my suggestion of marking types go, you are right, it doesn't make > sense for most types. It really only matters for structs and pointers. > Imagine if structs had an "isRoot" flag that lived next to "isPacked", which > makes the struct a distinct type. This would be written in IR as "gcroot { > i1, float }" or something like that. The presence of this flag has the same > effect as marking a pointer in the GC address space. Combine that with the > ability to mark SSA values a...

...te a StructType to contain func_add StructType *myStructType = StructType::create(module->getContext(), "myStruct"); std::vector<Type*> fields; fields.push_back(func_add->getType()); if (myStructType->isOpaque()) { myStructType->setBody(fields, /*isPacked=*/false); } string myGVName = "myGV"; // create a GlobalVariable to store myStruct GlobalVariable* mainGV = new GlobalVariable( /*Module=*/*module, /*Type=*/myStructType, /*isConstant=*/false, /*Linkage=*/GlobalValue::ExternalLinkage, /*Initializer=...