search for: setbody

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... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150717/7a81e3c8/attachment.html>

...lows a fairly extensive set of recursive declarations. It looks like I can translate all its high-level types using four llvm types that refer to another type: function, struct, pointer, and array. It looks like I can alter an llvm struct type in place after it has been created, using StructType::setBody. I don't see a way to do this for the other three. I have to handle cases such as an array type of pointers to itself (OK, not very useful, but legal, and I should handle it) and, quite realistically, a function with a parameter or result that is a pointer to itself. In general, I can get ty...

...:get(context, 64)); and type definitions: auto *constint1 = llvm::ConstantInt::get(context, llvm::APInt(64, 1)); auto *int64Ty = llvm::IntegerType::get(context, 64); auto *doubleTy = llvm::Type::getDoubleTy(context); auto *structTy = llvm::StructType::create(context, "Foo"); structTy->setBody({int64Ty, doubleTy}); auto *pointerTy = llvm::PointerType::get(structTy, 0); take care that the "size" is a "llvm::Value" type, not a "llvm::constantInt" type, this leads to a problem: definitions like "int i[sizeof(Foo)]" will fail (please ignore that this...

...tch for this?  Can you create a branch of the clang repo or send an updated version of the patch to the list? I've created a clang type-system-rewrite branch and committed all my purely mechanical changes: de-constifying llvm::Types as necessary, and using the new llvm::StructType::createNamed/setBody to create the "implicit" structs used by things like the Objective-C runtime. I haven't committed anything to do with updating the general Clang -> LLVM type conversion machinery, because I don't know when or whether I'll be able to get it finished. If anyone else wants to...

...'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 with the C API. It should be very straight-forward: just expose a wrapper for "StructType::setBody" and "StructType::createNamed". Some motivation for the change is here: http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt -Chris

My apologies if this has already been discussed/explained (reference?). In browsing the new type system implementation, I was wondering if someone could give a simple example of why one would want to reset the name of a previous realized StructType instance (setBody(...) has been called). My curiosity is enhanced by the fact that reseting a name of a StructType instance may result in a symbol table collision which would result in the renamed name not matching the parameter name to setName(...). This question is for my own edification. It is not rhetorical....

..... merging. It should now read: > > The biggest and most pervasive change is that the type system has been rewritten: PATypeHolder and OpaqueType are gone, and all APIs deal with Type* instead of const Type*. If you need to create recursive structures, then create a named structure, and use setBody() when all its elements are built. Type merging and refining is gone too: named structures are not merged with other structures, even if their layout is identical. (of course anonymous structures are still uniqued by layout). > Looks good to me, please commit! -------------- next part ------...

...uires user to handle padding 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 comme...

Hi, I'm having a play with LLVM to implement a custom language (for my intellectual curiosity only). I'm wondering how, when using IRBuilder, one can can it to emit a recursive type definition? The code for TypeBuilder explicitly states that it doesn't handle recursive types... I'm after being able to emit, programmatically, stuff like the Named Types example in the Language

With StructType you can create an empty structure and then call setBody later. How can one do the same thing with a PointerType? I'm translating a recursive structure which includes pointers to itself. I end up creating multiple copies of logically equivalent pointer types. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --...

I'm building a StructType without a body using StructType *StructType::create(LLVMContext &Context, StringRef Name); and then later adding a body to with setBody(). It starts of isOpaque() == true, and isSized() == false, and after 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,...

...8, %s } define %s @foo(%s* %a) { %y = load %s* %a ret %s %y } %s2 = type { i32, %s3} %s3 = type { i8, %s2} declare %s3 @foo2(); Similarly it is doable via the API: create a named struct, create elements where one refers directly to the newly created struct (instead of pointer), and then setbody. I can't see how such a type can be useful (I created it by accident, meant to use pointer-to struct, not struct type directly), and in fact llvm-dis crashes on bitcodes with infinetely recursive struct types. I'd suggest that such infinetely (mutually-)recursive struct types should be re...

...ges twice... merging. It should now read: The biggest and most pervasive change is that the type system has been rewritten: PATypeHolder and OpaqueType are gone, and all APIs deal with Type* instead of const Type*. If you need to create recursive structures, then create a named structure, and use setBody() when all its elements are built. Type merging and refining is gone too: named structures are not merged with other structures, even if their layout is identical. (of course anonymous structures are still uniqued by layout). Ok to commit? Joe Joe Abbey Software Architect Arxan Technologies, In...

...ggest problem I've found is that Clang uses LLVM's type resolution not just for forward-declared structs/classes/unions, which convert straightforwardly to the new system, but also for forward-declared enums, which don't. Also, varargs forms of StructType::createNamed() and StructType::setBody() would save a lot of mindless churn in the Clang source code. Jay.

Hi Chris, > 3. Clang/dragonegg need to adapt to the new API (help appreciated!) what needs to be done exactly? Ciao, Duncan.

The first draft of the LLVM 3.0 release notes now done, in llvm/docs/ReleaseNotes.html (the web page isn't autoupdating at the moment). Please take a look and make corrections or enhancements as you see fit. There are still a few things that I need from specific people (marked with XXX's): - BillW is writing a blog about exception handling. - The llvm.expect intrinsic isn't documented

An update on the type-system-rewrite branch (http://llvm.org/viewvc/llvm-project/llvm/branches/type-system-rewrite/): It's now to the point where it passes all regression tests all of single source (and most of externals/multisource) when using an LLVM 2.9 version of clang to compile programs to a rbc file. I have what looks like one more subtle type mapping bug to track down, which will

...s* %a > ret %s %y > } > > %s2 = type { i32, %s3} > %s3 = type { i8, %s2} > > declare %s3 @foo2(); > > Similarly it is doable via the API: create a named struct, create elements where one refers directly to the > newly created struct (instead of pointer), and then setbody. > > I can't see how such a type can be useful (I created it by accident, meant to use pointer-to struct, > not struct type directly), and in fact llvm-dis crashes on bitcodes with infinetely recursive struct types. > > I'd suggest that such infinetely (mutually-)recursive...

Hi Rick, On 22/01/13 09:04, Rick Mann wrote: > I'm building a StructType without a body using > > StructType *StructType::create(LLVMContext &Context, StringRef Name); > > and then later adding a body to with setBody(). It starts of isOpaque() == true, and isSized() == false, and after I add the body, isOpaque() == false, but isSized() is still false. this is the standard way of making a struct type, so I suspect you made a mistake such as adding an opaque field to the struct (this will stop it from having a s...

Hi, Question 1: Will the new type system allow to incrementally build structs (instead of filling all the fields in one go, as in the example given in <http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt>? Question 2: Will the ocaml bindings to be updated to work with the new type system once the merging of the rewrite to the main branch is done? Thanks very much, N