Re: Link-time optimzation

[Richard Henderson <rth at redhat dot com>]

On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
>   http://gcc.gnu.org/projects/lto/lto.pdf

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.

Section 2.2.1

  "invalid if and of"
  s/and/any/

  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.

Section 2.2.2

  You don't specifically mention arrays with differing ranges, but
  identical numbers of elements.  E.g. 0 to 5 and 1 to 6.

Section 3.4

  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.

Section 4.1

  Some more detail on what you have in mind wrt mapping scopes would
  be nice.

  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.

Section 4.2

  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
can work.


r~