Re: [lto]: PATCH: Add output of functions.

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>> This patch is the first cut at writing the gimple function bodies into
>> the asm file.  This is a rewrite of my last patch with all of the dwarf3
>> removed and many issues addressed.  This is now writing to the assembly
>> file and a lot more of it is table driven, which will also be used on
>> the reading side. 
>
> Exciting.
>
>> The interface with CodeSourcery's symbol table code to get references to
>> the global types and decls is there but is ifdef'ed out with the
>> preprocessor symbol GIMPLE_SYMBOL_TABLE_WORKS.
>
>> Right now the symbol table code has little behind it except calls to
>> abort.
>
> Well, types (are supposed to) work -- so you might as well turn that
> bit on. :-)  And, since CONST_DECLs have no semantics, I don't expect
> that we'll ever provide an API for writing them out, so you can drop
> that bit too.  I think that it's great that you're trying to make sure
> you can push lots of input code through your code, but it's going to
> be a while before we can get all of that working on both sides, so I
> think you'll need to work with toy programs at first.
>
This did not work, or did not always work when I tried it before.  I
think your side should play with them and uncomment them as they start
working. 

As far as the DECL_CONSTs, I do not know what you mean.  Something has
to be written out somewhere so that they can be regenerated on the other
side.  Unless you are saying that just putting in a NULL_TREE in the
their place is the right thing to do. 

>> One piece of the api that has slipped through the cracks is what am I to
>> name the sections that the output is in. 
>
> I suggest ".lto_$name", where $name is the function's
> DECL_ASSEMBLER_NAME.  We should also select an ELF section type number
> from the reserved portion of the number space, but that's a detail we
> can postpone.
I will change this today and get it up. 
>
> If you agree, Sandra and I will wire up enough bits to read a
> FUNCTION_DECL, call the reader, using the API previously agreed, and
> generate code within a few days.  Theoretically, that should allow us
> to round-trip small programs.
>

It will take me a few days to get the reader written anyway.  Getting
more of the global decls and types working would most likely be more
useful now. 


Kenny