Prague GCC folks meeting summary report

Prague GCC folks meeting summary report

[Richard Guenther]

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.

Re: Prague GCC folks meeting summary report

[Jeff Law]

On 09/24/09 04:35, Richard Guenther wrote:.
> .  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.
>
>    
No argument from me re: hppa moving to secondary status. IIRC, HP has 
stopped selling new PA systems and will stop selling upgrades to 
existing systems at the end of this year.

Jeff

Re: Prague GCC folks meeting summary report

[Joseph S. Myers]

On Thu, 24 Sep 2009, Richard Guenther wrote:

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

If queueing a warning you need to be careful about i18n - probably queue 
the exact text that would be emitted (as affected by options such as 
-fdiagnostics-show-*) and then make sure it does not get passed through 
translation again.

Other cases for queueing warnings are where the issue is not unreachable 
code but some other property that may be proved during optimization, such 
as whether an expression implicitly converted from signed to unsigned can 
ever actually be negative.  There are several places where the C front end 
lowers expressions (calls c_fully_fold) prematurely to avoid bogus 
warnings in such cases, and if all folding (and probably then the other 
lowering c_fully_fold does) is to be moved to gimplification time or later 
then a solution to these warnings is needed.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Prague GCC folks meeting summary report

[Joseph S. Myers]

On Thu, 24 Sep 2009, Richard Guenther wrote:

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

Can we map -combine to use LTO transparently in 4.6 (deprecate the 
implementation, keep the interface)?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Prague GCC folks meeting summary report

[Richard Guenther]

On Thu, 24 Sep 2009, Joseph S. Myers wrote:

> On Thu, 24 Sep 2009, Richard Guenther wrote:
> 
> > 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.
> 
> Can we map -combine to use LTO transparently in 4.6 (deprecate the 
> implementation, keep the interface)?

We thought about that, but the issue with LTO is that you need to
use the gcc driver at link time and pass -flto there.  But yes,
in principle you could continue to handle -combine in the driver
by doing the link step to build an object file.  Supporting it
on cc1 is probably not going to work though.

Is -combine widely used?  IIRC it has a lot of known issues and
is basically unmaintained.  Maybe if we deprecate -combine for 4.5
we'll get feedback if it is used.

Richard.

Re: Prague GCC folks meeting summary report

[Kevin P. Fleming]

Richard Guenther wrote:

> Is -combine widely used?  IIRC it has a lot of known issues and
> is basically unmaintained.  Maybe if we deprecate -combine for 4.5
> we'll get feedback if it is used.

I have used it quite a bit, but now most often I just use a single
source file full of #include statements to achieve the same end as it
works with versions of GCC where -combine is broken (or not available).

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kpfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

Re: Prague GCC folks meeting summary report

[Andi Kleen]

Richard Guenther <rguenther@suse.de> writes:
>
> 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.

Is that really the right level? In my experience (very roughly) -g can turn gcc from
CPU bound to IO bound (especially considering distributed compiling appraches),  
and dropping unnecessary information in external tools would make the IO penalty even 
worse.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Prague GCC folks meeting summary report

[Joe Buck]

On Thu, Oct 01, 2009 at 05:00:10PM -0700, Andi Kleen wrote:
> Richard Guenther <rguenther@suse.de> writes:
> >
> > 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.
> 
> Is that really the right level? In my experience (very roughly) -g can turn gcc from
> CPU bound to IO bound (especially considering distributed compiling appraches),
> and dropping unnecessary information in external tools would make the IO penalty even
> worse.

Certainly life can suck when building large C++ apps with -g in an NFS
environment.  Assuming we can generate tons of stuff and strip it later
might not be best.

Re: Prague GCC folks meeting summary report

[Richard Guenther]

On Thu, 1 Oct 2009, Joe Buck wrote:

> On Thu, Oct 01, 2009 at 05:00:10PM -0700, Andi Kleen wrote:
> > Richard Guenther <rguenther@suse.de> writes:
> > >
> > > 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.
> > 
> > Is that really the right level? In my experience (very roughly) -g can turn gcc from
> > CPU bound to IO bound (especially considering distributed compiling appraches),
> > and dropping unnecessary information in external tools would make the IO penalty even
> > worse.
> 
> Certainly life can suck when building large C++ apps with -g in an NFS
> environment.  Assuming we can generate tons of stuff and strip it later
> might not be best.

The agreement was based on the fact that 1) full debuginfo is necessary
anyway (for -debuginfo packages) 2) we don't want to build a package
multiple times just to get different levels of retained debug information.
So the way it will work is that -debuginfo package generation will
strip all but the pieces that should be retained in the binary.

To make the above work first the external tools have to add the 
capabilities, just implementing it in GCC doesn't work for us.

Richard.

Re: Prague GCC folks meeting summary report

[Andi Kleen]

> To make the above work first the external tools have to add the 
> capabilities, just implementing it in GCC doesn't work for us.

Ok, but there's more to building software, than just building rpms.

For example I can definitely see a common use case where a program
is built with line number and unwinding information, but not with types.
Or types are only generated partially using a special "debug file".

And for that it would be best if gcc simply didn't generate unnecessary
information and minimizes IO and disk space requirements.

iirc there was even a patch in this direction from Frank Ch. Eigler

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.