From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26098 invoked by alias); 27 Jul 2010 17:10:43 -0000 Received: (qmail 26084 invoked by uid 22791); 27 Jul 2010 17:10:41 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_CF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Jul 2010 17:10:33 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6RHA0dB010339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Jul 2010 13:10:00 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6RH9xL5006734; Tue, 27 Jul 2010 13:09:59 -0400 Received: from [10.3.113.34] (ovpn-113-34.phx2.redhat.com [10.3.113.34]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o6RH9uHj007424; Tue, 27 Jul 2010 13:09:57 -0400 Message-ID: <4C4F12E4.5050107@redhat.com> Date: Tue, 27 Jul 2010 17:39:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1 MIME-Version: 1.0 To: Bernd Schmidt CC: Eric Botcazou , Paolo Bonzini , gcc-patches@gcc.gnu.org, Steven Bosscher , Jim Wilson Subject: Re: ifcvt/crossjump patch: Fix PR 42496, 21803 References: <4BB3CCCA.7000600@codesourcery.com> <4C4D903F.9080405@gnu.org> <4C4D9264.2020505@codesourcery.com> <201007270944.06131.ebotcazou@adacore.com> <4C4EA526.8050508@codesourcery.com> In-Reply-To: <4C4EA526.8050508@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: 2010-07/txt/msg02104.txt.bz2 On 07/27/10 03:21, Bernd Schmidt wrote: > In particular, I want to avoid kludges like: >> +/* Set to true if we couldn't run an optimization due to stale liveness >> + information; we should run df_analyze to enable more opportunities. */ >> +static bool block_was_dirty; >> >> @@ -2182,6 +2449,9 @@ try_optimize_cfg (int mode) >> && try_crossjump_bb (mode, EXIT_BLOCK_PTR)) >> changed = true; >> >> + if (block_was_dirty) >> + df_analyze (); >> + >> #ifdef ENABLE_CHECKING >> if (changed) >> verify_flow_info (); >> >> that shouldn't be necessary. > Still not an argument. Why shouldn't it be necessary? It is logical > that by moving code, we change the liveness of registers. We have to > verify the liveness of registers before moving code, hence, to iterate, > we have to recompute it. It seems to me implementing this optimization well requires insn movement which is going to affect register lifetimes. Furthermore, this optimization is sitting inside a while (changed) style loop. At the least we need to mark blocks where the life data has become inaccurate so that we don't mis-optimize based on inaccurate life data. I haven't thought deeply about the problem, but it may well be the case that as the cfgcleanup loop iterates new opportunities may be exposed and thus it'd be useful to go ahead and update the life information. What I'm more concerned about is placement of this optimization in cfgcleanup -- one could argue this optimization isn't strictly a cfg cleanup given the need to move insns from one block to another (contrast to our cross jumping implementation which just scrambles the cfg). One could formulate a head merging algorithm which worked solely on the CFG, but I doubt it's going to be very effective. jeff