From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21143 invoked by alias); 12 Nov 2007 23:00:45 -0000 Received: (qmail 21115 invoked by uid 22791); 12 Nov 2007 23:00:35 -0000 X-Spam-Check-By: sourceware.org Received: from mx-out.libertysurf.net (HELO mail.libertysurf.net) (213.36.80.91) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 12 Nov 2007 23:00:32 +0000 Received: from [192.168.1.3] (91.164.35.185) by mail.libertysurf.net (7.3.118.8) id 470CEC87004FB834; Tue, 13 Nov 2007 01:02:21 +0100 From: Eric Botcazou To: "Steven Bosscher" Subject: Re: Fix PR rtl-optimization/34035 Date: Tue, 13 Nov 2007 01:51:00 -0000 User-Agent: KMail/1.7.1 Cc: gcc-patches@gcc.gnu.org References: <571f6b510711121328m4099a054o6225a71c84a582f@mail.gmail.com> <200711122249.46295.ebotcazou@libertysurf.fr> <571f6b510711121422q467365edp4c7dce908714fc5a@mail.gmail.com> In-Reply-To: <571f6b510711121422q467365edp4c7dce908714fc5a@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200711130001.33692.ebotcazou@libertysurf.fr> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00680.txt.bz2 > With cleanup_cfg(0) you add another delete_trivially_dead_insns() > pass, and three iterations over all basic blocks. This does seem, at > first, to be quite cheap. The problem is that we do it all over the > place when it actually doesn't buy you anything: The "good" rtl passes > look through the dead code that d_t_d_i can remove, and even the > semi-good passes don't care about an extra forwarder block or a > single_succ block here and there. cleanup_cfg (0) is the canonical invocation to minimally clean up the CFG at the end of the RTL passes. It is already run at the end of every CSE and GCSE pass if a single jump is modified. We now also invoke it on demand in, I believe, relatively rare cases. > IMO much of gcc's abysmal compile time performance can be blamed on > doing redundant work all over the place, trying hard for little gain. > Sorry to jump on your patch like this, but it just looks like > "obvious" redundant cfg cleanup work (bikeshed, bikeshed! ;-) I don't think cleanup_cfg (0) is "trying hard"; otherwise tree optimization passes shouldn't be allowed to set TODO_cleanup_cfg. That being said, if you can come up with a testcase, I'll revise my position. Of course don't try with C, C++ or Fortran, the change only affects those languages for which -fnon-call-exceptions is set, e.g. Ada that I specially care about. -- Eric Botcazou