[LLVMdev] Order of fields and structure usage

[Hendrik Boom]

On Sat, 13 Sep 2008 11:45:50 -0700, Eli Friedman wrote:

> On Sat, Sep 13, 2008 at 11:09 AM, Hendrik Boom <hendrik at topoi.pooq.com>
> wrote:
>> What I want is to be able to use the fields that have already been
>> defined, even though the type isn't complete yet.  The vector<const
>> Type*> is all I have at that moment, and it isn't a type.  But by the
>> time I have a type it's frozen and I can't add new fields to it.
>>
>> Do I gather that I keep making new types, each slightly larger than the
>> previous ones, cast each pointer to my growing type to the type-of-the-
>> moment, and field-select from it;  then finally complete the type when
>> all is known?  That might just work, if field-allocation is independent
>> of later fields, but it is ugly.
> 
> Field-allocation is guaranteed to be independent of later fields, so the
> casting solution would work.
> 
> It might be slightly cleaner to define the types recursively... for
> example, define a struct as { i32 { float { i32* } } }.  That way, you
> wouldn't have a bunch of partial types floating around.
> 
> -Eli

Looking at this again, the conceptual problem is this.

It's natural in writing a code generator to want to generate code out of 
order.

Given a suitable representation of strings, or temporary files, it's 
rather easy to do this if the generated fore is text.  You just make sure 
you can make insertions where you want, or stratify the code into 
different temporary files that are later concatenated, or something like 
that.  With today's gigabyte RAM chips, this isn't a big deal.  So all 
would be well generating llvm assembler.

But then I see the API to llvm that allows one to build the llvm parse 
tree directly, without making a huge string that has to be written out 
and parsed.  It seems designed for the typical case -- that code will be 
generated out of order.  You can remember insertion points into the parse 
tree, and inject things as needed.

Except that this does not work with types.  llvm assembler has type 
declarations, which are as jugglable and expandable as any other piece of 
text -- until thep generated code is complete and everything is written 
out for reading and parsing.  The parse tree, however, doesn't seem to 
have a syntax for type declarations -- it only has types,  It is not a 
parse tree for the llvm assembler.  It is something else, something 
slightly different, but different enough to cause trouble.

And that's the whole difference.

-- hendrik