similar to: [LLVMdev] LLVM IR Type System Rewrite

On Sat, Feb 26, 2011 at 10:25 PM, Chris Lattner <clattner at apple.com> wrote: > 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! So struct types would unique by name. How

On 11-02-26 4:25 PM, Chris Lattner wrote: > 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 Thanks! > Comments welcome! Having fewer types makes the job of the passes easier. Right now we maintain a

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

Hey Chris, On Sat, Feb 26, 2011 at 1:25 PM, Chris Lattner <clattner at apple.com> wrote: > 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 Awesome! This is definitely long overdue... Proposal seems

On 26 February 2011 21:25, Chris Lattner <clattner at apple.com> wrote: > 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 Hi Chris, I don't see such a bad problem with PATypeHolder, but I get what

Hi Chris I have questions about new IR. > Named structs. > Unnamed structs (named structs with no names) > Anonymous structs (things like complex, which cannot be cyclic) > >Given this, the rules above would be that "only non-anonymous structs can have >cycles" for example. Arrays, pointers and other non-namable types can be >considered to be anonymous as well.

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

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

On 25 June 2011 13:00, Duncan Sands <baldrick at free.fr> wrote: >> 3. Clang/dragonegg need to adapt to the new API (help appreciated!) > > what needs to be done exactly? Background info: http://www.nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt As I understand it, PATypeHolder, OpaqueType and the Module's TypeSymbolTable are gone. Instead, StructTypes can optionally be

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

With the named/unnamed/anonymous distinctions there seems to be two things going on: 1. Giving an ID to a struct type. 2. Naming a type for readability. Would the new system force anonymous structs to be printed inline at every occurrence? The code might become hard to read with large anonymous types. Would it make sense to have both ID and Name? If a type has a name it could be printed using

Chris Lattner wrote: > 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

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

With primitive types, I can interchange literal usage and type aliases in IR: %mytype = type i32 define void @foo(%mytype* %ptr) { %t1 = load *%mytype** %ptr store i32 *%t1*, *i32** %ptr ret void } But for structs, I cannot: %mytype = type { i32, i32 } define void @foo(%mytype* %ptr) { %t1 = load *%mytype** %ptr store* { i32, i32 }* %t1, *{ i32, i32 }** %ptr ret void }

On Feb 27, 2011, at 9:48 AM, Rafael Ávila de Espíndola wrote: >> Comments welcome! > > Having fewer types makes the job of the passes easier. Right now we > maintain a small number of types as we go, which is expensive. In the > proposed change, would it still be legal to write a type merging pass? > For example, lets say we have > > %Foo = type { i32 } >

Hi, how can i correctly calculate the size of a member of a struct (including alignment etc)? This doesn't work : const StructType *STy = cast<StructType>(Ty); for (StructType::element_iterator I = STy->element_begin(), E = STy->element_end(); I != E; ++I) { usigned size =I->get()->getScalarSizeInBits(); //often

I'm implementing c style "sizeof()", and I did as http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt illuarstrated, and it works find, here's an example of my implementation: auto *p = builder.CreateGEP(structTy, llvm::ConstantPointerNull::get(pointerTy), constint1); auto *size =

Justin, http://llvm.org/docs/LangRef.html#structure-type "Identified types can be recursive, can be opaqued, and are never uniqued." Do you think it would be less descriptive? "Identified type, aka named llvm::StructType, is never uniqued against other identified types nor literal types, aka unnamed StructType(s)." ? See also;

LLVM Newbie here. I have the following C++ program using namespace std; struct A{ int i; int j; }; int main() { struct A obj; obj.i = 10; obj.j = obj.i; return 0; } Using clang++, I can see that LLVM IR contains struct field as below %struct.A = type { i32, i32 } I would like to obtain the structure elements using LLVM Pass. I write the following program - that iterates

Hi James, Sorry I missed this. Please send things to the list, not to me directly. On Jul 20, 2011, at 9:52 PM, james woodyatt wrote: > One thing that springs to mind after reading the <http://nondot.org/sabre/LLVMNotes/TypeSystemRewrite.txt> note is that the vocabulary seems a bit confusing. > >> This argues for terminology along the lines of: >> >> Named