This is the mail archive of the
mailing list for the GCC project.
Re: Link-time optimzation
- From: Richard Henderson <rth at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Wed, 16 Nov 2005 17:19:00 -0800
- Subject: Re: Link-time optimzation
- References: <437BB214.email@example.com>
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
In Requirement 4, you say that the function F from input files a.o and
b.o should still be named F in the output file. Why is this requirement
more than simply having the debug information reflect that both names
were originally F? I see you go to some length in section 3 to ensure
actual symbol table duplicates, and I don't know why.
The rest of the requirements look good. I cannot immediately think of
anything you've forgotten.
"invalid if and of"
By focusing on c99 inline functions, you've forgotten the facts
of gcc inline functions. I'll give you a guess as to which set
of semantics are actually used in practice. Note that gcc's
inline semantics are a superset of both C++ and c99, and that
gcc doesn't actually implement c99 semantics at all.
You don't specifically mention arrays with differing ranges, but
identical numbers of elements. E.g. 0 to 5 and 1 to 6.
I don't think I understand how you plan to not duplicate code from
ld to locate the set of object files. The only way I can think of
is for ld to actually extract the objects into new temporary files.
Perhaps I've forgotten how much effort is involved here, but I can
see it being easier to just duplicate this code and forget it.
Some more detail on what you have in mind wrt mapping scopes would
My initial thought is that you wouldn't need anything special at
all. Just refer to the scopes from within the IL by offset within
the CIE. Perhaps I'm missing something that makes this hard.
What is the rationale for using a stack-based representation rather
than a register-based representation? A infinite register based
solution would seem to map better onto gimple, making it easier to
understand the conversion into and out of. The required stacking
and unstacking operations would seem to get in the way.
C.f. plan9's inferno, rather than jvm or cil.
I'll say that I do like the notion of emitting the type and symbol
tables as normal dwarf3 output. Especially since your proposal seems
to call for regular code to be emitted simultaneously, so that ld -r