Prague GCC folks meeting summary report

[Richard Guenther <rguenther@suse.de>]

Present: Jakub Jelinek, Jan Hubicka, Martin Jambor, Michael Matz,
         Paolo Bonzini, Petr Baudis, Richard Guenther
Not present but invited: Andreas Schwab, Zdenek Dvorak

The objective of this meeting was to have a discussion about the
development of GCC (and dependent tools and libraries) in the
next 12 month (which covers stage 3 of 4.5 and stage 1 of 4.6). (**)

I suggested the schedule for Stage 3 (see the current GCC 4.5 status
report).  A projected release date of Feb 2010 was considered ambitious.


For stage 3 we discussed several issues
 * there is the chance to do cleanups in the following areas
   - cgraph and pass manager following the unit-at-a-time gimplification change
   - expand from SSA / tuples, notably the possible removal of the
     tree_ann pointer in tree_base
   - move functions across files, in particular separate tuple stmt folding
     into a separate file, likewise separate builtin expansion from folding
 * we should look at compile-time and memory-usage to catch easy improvements
   that are possible (in particular figure out why free-lang-data doesn't
   give the improvements that were hinted by the initial aggressive
   implementation of Micha)
 * Jakub wants to update his RTL store-merging patch which would address
   a long-standing regression
 * stack-slot sharing (aka PR39604).  We convinced ourselves that explicitly
   representing the point where aggregates die in the IL is the way to go.
   A killing store from a new builtin function was suggested as a way to
   represent this (AGG = __builtin_undefined ()) and to cause the least
   issues with other pieces of the compiler.  The calls would be inserted
   while lowering BIND_EXPR to GIMPLE.  Micha volunteered to look
   into (pieces) of this.

We discussed about features we don't like (PCH and -combine).  PCH
is used but has the issue that improper use is not diagnosed and PCH
seems to be unmaintained.  We agreed on deprecating -combine for 4.5
though.

On the same line we looked at the current list of primary and
secondary targets and suggested (again) to demote i686-apple-darwin to
a secondary platform on the base that it is unmaintained.  We
recognize that it is used and gets many bugs filed against.
It was suggested to drop powerpc-apple-darwin from the list of
secondary platforms.  It was also suggested to change hppa2.0w-hp-hpux11.11
to ia64-hpux and to change s390-linux-gnu to s390x-linux-gnu in the
list of secondary targets.


For GCC 4.6 the following things were discussed.

The only major new feature on the table, as of now, is support
for transactional memory.

One goal for GCC 4.6 should be to make selected existing optimization
passes stronger in favor of eliminating redundant passes.

Lowering GIMPLE after loop optimizations was discussed.  This
covered things like exposing target specific constraints
such as addressing modes, register promotion and features like
widening multiplication.  Simplified expansion to RTL is a benefit here,
as well as fixing some regressions dating back to GCC 3.x.
This also relates to what Kenny talked about during his GCC Summit
presentation.

On the early debug information side (emitting debug information for
global types and decls when the frontend is still around) it was
suggested to simply use DWARF as the representation that LTO would
use (streaming out DWARF and reading it back in).  Relying on
a library here was suggested, libdw came up.  It was noted that
debug information for C should be possible with LTO even without
early debug info generation.

The wish for more granular and thus smaller debug information (things like
-gfunction-arguments which would properly show parameter values
for backtraces) was brought up.  We agree that this should be addressed at a
tools level, like in strip, not in the compiler.

The regular problem of emitting warnings for unreachable code may
be addressed by using a new variant of debug statements.  Those
would queue up warnings and if still around emit them during
expansion.  Currently queueing a warning can be done with inserting
a __builtin_warning function call.

During GCC 4.6 development most IPA passes need TLC for being useful
for WHOPR.

We for quite some time discussed how to best add unit-testing to GCC.
Two ideas are there - 1) allow extra passes to be enabled on top of -O0
2) have a textual representation of GIMPLE and use lto1 as a driver
for unit-testing.  We bikeshedded about this textual representation a bit.
Looking at the textual representation LLVM uses might be a good idea.

Shortly mentioned but not really discussed were the no-undefined-overflow
branch (I plan to work on this) and the middle-end arrays (fun but
low priority for me, the Fortran frontend pieces are scary).

--
Richard.


Disclaimer: opinions and plans that emerged during the
meeting do not necessarily reflect decisions or the opinion of the
GCC (developer) community.

(**) The real objective was of course to have fun.  The fun parts are
not covered by this report.