llvm dev - Jun 2008 - [LLVMdev] code generation order revisited.

>>
>> I think I may have found an exception to this -- the API seems to  
>> require me to have all the fields for a struct ready before I  
>> construct the struct.  I don't have the ability to make a struct  
>> type, use it to declare some variables, and still contribute fields  
>> to it during the rest of the compilation.
>>
>> Is there a reason for this limitation other than no one thinking of  
>> it? Does it need to have all the type information early in building  
>> the parser tree?  I can't really imagine that.  I for one could do
>> without this limitation.
> 
> You really can't do this since LLVM types are shape isomorphic.  
> Observe what happens to the types of @x and @y:
> 
>      gordon$ cat input.ll
>      %xty = type {i32}
>      %yty = type {i32}
>      @x = external constant %xty
>      @y = external constant %yty
> 
>      gordon$ llvm-as < input.ll | llvm-dis
>      ; ModuleID = '<stdin>'
>              %xty = type { i32 }
>              %yty = type { i32 }
>      @x = external constant %xty ; <%xty*> [#uses=0]
>      @y = external constant %xty ; <%xty*> [#uses=0]
> 
> (This is not a side-effect of llvm-as or llvm-dis, but a fundamental  
> property of the LLVM 'Type' class.)
> 
> The only type that is not shape-isomorphic is 'opaque'. Each
mention
> of 'opaque' in LLVM IR is a distinct type:
> 
>      gordon$ cat input2.ll
>      %xty = type opaque
>      %yty = type opaque
>      @x = external constant %xty
>      @y = external constant %yty
> 
>      gordon$ llvm-as < input2.ll | llvm-dis
>      ; ModuleID = '<stdin>'
>          %xty = type opaque
>          %yty = type opaque
>      @x = external constant %xty ; <%xty*> [#uses=0]
>      @y = external constant %yty ; <%yty*> [#uses=0]
>
So it appears that types are processed for identity the moment they are
made during parse tree construction? This means that a type has to be
completely known on creation.  Presumably there's some mechanism tor a
type that isn't completely known yet -- or is thet avoided by having a
type 'pointer' instead of 'poimter-to-foo'?

-- hendrik

On Jun 12, 2008, at 13:25, Hendrik Boom wrote:
> So it appears that types are processed for identity the moment they  
> are made during parse tree construction?
Yes.
> This means that a type has to be completely known on creation.
Yes.
> Presumably there's some mechanism tor a type that isn't completely
> known yet -- or is thet avoided by having a type 'pointer' instead
> of 'poimter-to-foo'?
Partially opaque types can be refined. This section of the  
programmer's manual is applicable:

http://llvm.org/docs/ProgrammersManual.html#BuildRecType

— Gordon

On Thu, 12 Jun 2008 16:05:19 -0400, Gordon Henriksen wrote:
> 
> Partially opaque types can be refined. This section of the programmer's
> manual is applicable:
> 
> http://llvm.org/docs/ProgrammersManual.html#BuildRecType
> 
> — Gordon
Here it is:

: // Create the initial outer struct
: PATypeHolder StructTy = OpaqueType::get();
: std::vector<const Type*> Elts;
: Elts.push_back(PointerType::get(StructTy));
: Elts.push_back(Type::Int32Ty);
: StructType *NewSTy = StructType::get(Elts);

Here NewSTy is a pointer to StructType.

: // At this point, NewSTy = "{ opaque*, i32 }". Tell VMCore that
: // the struct and the opaque type are actually the same.
: cast<OpaqueType>(StructTy.get())->refineAbstractTypeTo(NewSTy);

: // NewSTy is potentially invalidated, but StructTy (a PATypeHolder) is
: // kept up-to-date
: NewSTy = cast<StructType>(StructTy.get());

At first I couldn't see the purpose of this statement, because presumably 
NewSTy is already that StructType.  But then I noticed that here we are 
assigning a StructType to a variable that is pointer-to-StructType 
instead.  So I don't even know what I should be wondering about.

: // Add a name for the type to the module symbol table (optional)
: MyModule->addTypeName("mylist", NewSTy);

-- hendrik