[LLVMdev] code generation order revisited.

[Hendrik Boom]

>>
>> 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