This is the mail archive of the
mailing list for the GCC project.
Re: [lto]: PATCH: Add output of functions.
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, "Berlin, Daniel" <dberlin at dberlin dot org>, "Edelsohn, David" <dje at watson dot ibm dot com>, drow at false dot org
- Date: Fri, 08 Sep 2006 07:47:57 -0400
- Subject: Re: [lto]: PATCH: Add output of functions.
- References: <45007C7D.firstname.lastname@example.org> <4500F55E.email@example.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.
>> 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
> 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
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