This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

LTO Status

Several people have asked for an update on the status of the LTO
project, so Kenny and I have put together a summary of what we believe
the status and remaining issues to be.

The short story is that, unfortunately, we have not had as much time as
we would have liked to make progress on LTO.  Kenny has been working on
the dataflow project, and I have had a lot of other things on my plate
as well.  So -- as always! -- we would be delighted to have other people
helping out.  (One kind person asked me if contributing to LTO would
hurt CodeSourcery by potentially depriving us of contracts.  I doubt
that very much, and I certainly don't think that should stop anybody
from contributing to LTO!)

I still think that LTO is a very important project, and that the design
outline we have is sound.  I think that a relatively small amount of
work (measured in terms of person-months) is required to get us to being
able to handle most of C.

Mark Mitchell
(650) 331-3385 x713

  This document summarizes work remaining in the LTO front end to
  achieve the initial goal of correct operation on single-file C

Changes to the DWARF Reader Required

  The known limitations of the DWARF reader are as follows:

  * Modify 'LTO_READ_TYPE' to byte-swap data, as required for cross
    compiling for targets with different endianness.

  * The DWARF reader skips around in the DWARF tree to read types.
    It's possible that this will not work in situations with complex
    nesting, or that a fixup will be required later when the DIE is
    encountered again, during the normal walk.

  * Function-scope static variables are not handled.

  * Once more information about types is saved (see below), references
    to layout_type, etc., should be removed or modified, so that the
    saved data is not overritten.

  * Unprototyped functions are not handled.

DWARF Extensions Required
  The following sections summarize augmentations we must make to the
  DWARF generated by GCC.

  GNU Attributes

    Semantic GNU attributes (e.g., dllimport) are not recorded in
    DWARF.  Therefore, this information is lost.

  Type Information

    At present, the LTO front end recomputes some type attributes (like
    machine modes).  However, there is no guarantee that the type
    attributes that are computed will match those in the original
    program.  Because there is presently no method for encoding this
    information in DWARF, we need to take advantage of DWARF's
    extensibility features to add these representations.

    The type attributes which require DWARF extensions are:

    * Type alignment

    * Machine mode

  Declaration Flags

    There are some flags on 'FUNCTION_DECL' and 'VAR_DECL' nodes that
    may need to be preserved.  Some may be implied by GNU attributes,
    but others are not.  Here are the flags that should be preserved.

    Functions and Variables: 





    * 'DECL_WEAK'






    * 'DECL_IS_PURE'
















Gimple Reader and Writer

  Current Status

    All gimple forms except for those related to gomp are now handled.
    It is believed that this code is mostly correct.

    The lto reader and the writer logically work after the ipa_cp pass.
    At this point, the program has been fully gimplified and is in fact
    in "low gimple".  The reader is currently able to read in and
    recreate gimple, and the control flow graph.  Much of the eh handing
    code has been written but not tested.

    The reader and writer can be compiled in a self checking mode so
    that the writer writes a text logging of what is is serializing into
    the object file.  The lto reader uses the same logging library to
    produce a log of what it is reading.  During reading, the process
    aborts if the logs get out of sync.

    The current state of the code is that much of the code to serialize
    the cfun has not been written or tested.  Without this part of the
    code, nothing can be executed downstream of the reader without

  Remaining Work

   The ipa reader works as if it was just as another front end.  While
   this is clearly the correct approach, it will require some
   additional engineering to actually work.  Front ends are expected
   to connect to the system much earlier in the stack of passes than
   having low gimple.  Some mechanism needs to be added so that the
   passes up to pass ipa_cp are skipped by the lto front end.

   As of when work was paused on the lto reader and writer, only a
   small amount of the type system was actually being gimplified.
   This meant that it was impossible to test much of the machinery on
   anything except the simplest examples.  There are certainly bugs
   that have not been detected because of this.

   The front ends still generate some rtl.  I do not know which front
   ends are still doing this, but there are no plans to serialize the
   rtl. Any front end that this will have to be fixed before they can
   play lto.  Likewise, fields in the cfun like "struct
   language_function * language;" are extremely problematic.

   There are still lang hooks that must be replaced with explicit
   semantics in the IL.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]