From patchwork Wed Jun 16 15:59:48 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Kuvyrkov X-Patchwork-Id: 55908 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 9AFCC1007D2 for ; Thu, 17 Jun 2010 01:59:59 +1000 (EST) Received: (qmail 22429 invoked by alias); 16 Jun 2010 15:59:57 -0000 Received: (qmail 22419 invoked by uid 22791); 16 Jun 2010 15:59:56 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Jun 2010 15:59:52 +0000 Received: (qmail 22804 invoked from network); 16 Jun 2010 15:59:50 -0000 Received: from unknown (HELO ?172.16.1.24?) (maxim@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jun 2010 15:59:50 -0000 Message-ID: <4C18F4F4.606@codesourcery.com> Date: Wed, 16 Jun 2010 19:59:48 +0400 From: Maxim Kuvyrkov User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jeff Law , gcc-patches Subject: 0007-Add-open-ended-comments.patch References: <4C18F225.2040509@codesourcery.com> In-Reply-To: <4C18F225.2040509@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org This patch adds several open-ended comments in gcse.c. I'll be happy if anyone can answer some of them, in which case I'll check in the answers, rather than questions :). Thank you, diff --git a/gcc/gcse.c b/gcc/gcse.c index c81d71c..7215063 100644 --- a/gcc/gcse.c +++ b/gcc/gcse.c @@ -3431,7 +3431,9 @@ process_insert_insn (struct expr *expr) For PRE, we want to verify that the expr is either transparent or locally anticipatable in the target block. This check makes - no sense for code hoisting. */ + no sense for code hoisting. + ??? We always call this function with (PRE == 0), which makes the checks + useless. */ static void insert_insn_end_basic_block (struct expr *expr, basic_block bb, int pre) @@ -3535,6 +3537,9 @@ insert_insn_end_basic_block (struct expr *expr, basic_block bb, int pre) else new_insn = emit_insn_after_noloc (pat, insn, bb); + /* ??? It maybe useful to try set REG_EQUAL note on NEW_INSN here. + How can we do it? */ + while (1) { if (INSN_P (pat)) @@ -4343,7 +4348,16 @@ hoist_code (void) index_map[expr->bitmap_index] = expr; /* Walk over each basic block looking for potentially hoistable - expressions, nothing gets hoisted from the entry block. */ + expressions, nothing gets hoisted from the entry block. + + ??? It maybe worthwhile to walk CFG in DFS order over the dominator tree. + One can imagine a case when a dominated block B is linked before + its dominator A, so if expressions were hoisted from blocks C and D, + which B (and A) dominates, then it may occur that we miss + an optimization of moving these expressions all the way to A. + Alternatively, we may handle this case by updating expressions' + occurences to include instructions emitted by code hoisting, i.e., + an expression emitted at the end of B will then be hoisted to A. */ FOR_EACH_BB (bb) { int found = 0;