From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17604 invoked by alias); 24 Sep 2009 10:35:16 -0000 Received: (qmail 17588 invoked by uid 22791); 24 Sep 2009 10:35:13 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Sep 2009 10:35:09 +0000 Received: from relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 1E1F474609 for ; Thu, 24 Sep 2009 12:35:07 +0200 (CEST) Date: Thu, 24 Sep 2009 10:35:00 -0000 From: Richard Guenther To: gcc@gcc.gnu.org Subject: Prague GCC folks meeting summary report Message-ID: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00501.txt.bz2 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.