From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8666 invoked by alias); 6 Sep 2011 10:37:21 -0000 Received: (qmail 8656 invoked by uid 22791); 6 Sep 2011 10:37:21 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ew0-f47.google.com (HELO mail-ew0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Sep 2011 10:37:04 +0000 Received: by ewy5 with SMTP id 5so2663098ewy.20 for ; Tue, 06 Sep 2011 03:37:03 -0700 (PDT) Received: by 10.213.110.11 with SMTP id l11mr440018ebp.54.1315305423229; Tue, 06 Sep 2011 03:37:03 -0700 (PDT) Received: from richards-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice1n1.emea.ibm.com [195.212.29.67]) by mx.google.com with ESMTPS id f3sm1633886eea.4.2011.09.06.03.37.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Sep 2011 03:37:02 -0700 (PDT) From: Richard Sandiford To: Bernd Schmidt Mail-Followup-To: Bernd Schmidt ,GCC Patches , richard.sandiford@linaro.org Cc: GCC Patches Subject: Re: Rename across basic block boundaries References: <4E00A296.4000306@codesourcery.com> <4E569522.7080008@codesourcery.com> <4E5F81C8.9050905@codesourcery.com> <4E64EBFA.5050004@codesourcery.com> Date: Tue, 06 Sep 2011 10:37:00 -0000 In-Reply-To: <4E64EBFA.5050004@codesourcery.com> (Bernd Schmidt's message of "Mon, 05 Sep 2011 17:34:18 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2011-09/txt/msg00370.txt.bz2 Bernd Schmidt writes: > On 09/01/11 16:16, Richard Sandiford wrote: >> Bernd Schmidt writes: >>> On 08/26/11 14:57, Richard Sandiford wrote: >>>> Wouldn't a reverse post-order (inverted_post_order_compute) allow even >>>> more pre-opening (as well as being less code)? >>> >>> I can't really tell from the comments what that function is supposed to >>> produce. >> >> Sorry, I thought it was supposed to produce a reverse postorder, but... >> >>> I've made a change to use it to order the bbs, but that made rr >>> visit basic blocks without seeing any of their predecessors first, >> >> ...I guess not. :-) pre_and_rev_post_order_compute should though. >> Could you try that instead? > > That seems to work for me. Looks good to me. Maybe here: > + /* The order in which we visit blocks ensures that whenever > + possible, we only process a block after at least one of its > + predecessors, which provides a "seeding" effect to make the logic > + in set_incoming_from_chain and init_rename_info useful. */ > + > + for (i = 0; i < n_bbs; i++) > + { > + basic_block bb1 = BASIC_BLOCK (inverse_postorder[i]); > + struct bb_rename_info *this_info = rename_info + i; > [...] > + if (bb1->aux == NULL) > + continue; it would be better to use: this_info = (struct bb_rename_info *) bb1->aux; if (this_info == NULL) continue; so that we don't care which order the rename_info array is. You could then keep the original form of the first loop: /* Gather some information about the blocks in this function. */ rename_info = XCNEWVEC (struct bb_rename_info, n_basic_blocks); ri_index = 0; FOR_EACH_BB (bb) { struct bb_rename_info *ri = rename_info + ri_index; ri->bb = bb; ri->n_preds = EDGE_COUNT (bb->preds); bb->aux = ri; ri_index++; } OK with me whichever. Richard