public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Diego Novillo <dnovillo@google.com>
To: gcc@gcc.gnu.org, java@gcc.gnu.org, Fortran List <fortran@gcc.gnu.org>
Subject: [LTO merge][0/15] Description of the final 15 patches
Date: Tue, 29 Sep 2009 00:58:00 -0000	[thread overview]
Message-ID: <b798aad50909281758s1bfe5a16pabc674b8a8d42fcc@mail.gmail.com> (raw)

I will be sending the final 15 patches to bring all the
functionality from the LTO branch.  I tried to divide the patches
along maintainer lines, but there are some overlaps

- C FE
	Adds processing of -flto and -fwhopr.

- C++ FE
	Adds a langhook used by need_assembler_name_p to handle
	templates.  This implements Jason's suggestion from
	http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00534.html

- Fortran FE
	Adds processing of -flto and -fwhopr.  Note that the
	Fortran testsuite still shows ~140 failures with LTO
	enabled.  IIUC, most of these have corresponding bugs
	filed and they are not LTO-related (in that LTO exposes
	some bugs in the FE).  We should discuss whether we want
	to include Fortran support for LTO in 4.5.

- Java FE
	There is no LTO support for Java, but since LTO uses
	zlib, Java does not need to include it.

- LTO FE
	This is the new front end for GIMPLE.

- Configury
	Detection of libelf, LTO support, etc.

- Contrib
	A minor patch to add lto-plugin to the timestamps.

- Documentation
	Documentation for the different LTO options.

- Driver
	The somewhat ugly changes to collect2 and the main gcc
	driver to support spawning lto1 when we detect a .o file
	with LTO sections in it.

- Streamer
	The code needed to support the on-disk representation of
	GIMPLE, CFG and cgraph.

- Langhooks
	New langhooks to support manipulating ELF sections and
	the new langhook for asking the FE if a DECL needs to
	have an assembler name set.

- libiberty
	I need help with this one.  When the linker plugin is
	enabled (if GCC is configured to use gold), LTO can
	detect LTO objects inside archives via the callbacks it
	gets from the linker.  Since the linker plugin is a
	shared object, and it uses libiberty functions, it needs
	to use a shared libiberty.

	Currently, we just force --enable-shared on libiberty,
	but I would only want to do that if gold and lto are
	enabled.  We detect gold and lto support in the top
	configure script, but how do I send that down to
	libiberty's configure?

- Linker plugin
	This is the set of callbacks that gold uses to talk with
	lto1 and resolve symbols out of object files in the link.

- Middle end
	All sorts of changes, mostly in the callgraph, IPA and
	pass manager.

- Testsuite
	New tests for LTO and new dejagnu support for writing LTO
	tests.  Most of this has already been reviewed by Janis.


Major outstanding work:

- Support for debugging information.  Currently, -flto -g does
  not work (no debug information is generated).  This is because
  free_lang_data does not preserve enough information for the
  debug hooks to emit it.  I will fix this during stage 3.

- Outstanding bugzilla (http://tinyurl.com/yarz5q9).

- Some 'FIXME lto' markers.  These are cleanup markers, several
  related to WHOPR.  We could probably debate whether to include
  the WHOPR functionality in 4.5.  It certainly is not very
  different from LTO, but it does need some TLC.

Once I get all the approvals I need, I will request trunk to be
frozen for a day or so to give me time to commit the whole thing.
I already have a merged local tree and this exact same code is in
the LTO branch.


Thanks.  Diego.

             reply	other threads:[~2009-09-29  0:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-29  0:58 Diego Novillo [this message]
2009-09-29  2:03 ` Joseph S. Myers
2009-09-29 14:48   ` Ian Lance Taylor
2009-09-29 14:56     ` Diego Novillo
2009-09-29 16:45     ` Paolo Bonzini
2009-09-29 16:53       ` Ian Lance Taylor
2009-09-29 16:56         ` Paolo Bonzini
2009-09-29 18:54           ` Ian Lance Taylor
2009-09-29  2:07 ` Joseph S. Myers
2009-09-29 13:06   ` Diego Novillo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b798aad50909281758s1bfe5a16pabc674b8a8d42fcc@mail.gmail.com \
    --to=dnovillo@google.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=java@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).