From patchwork Wed Jun 18 06:42:02 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhenqiang Chen X-Patchwork-Id: 32108 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-pd0-f198.google.com (mail-pd0-f198.google.com [209.85.192.198]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 85165206A0 for ; Wed, 18 Jun 2014 06:42:21 +0000 (UTC) Received: by mail-pd0-f198.google.com with SMTP id y10sf1362306pdj.5 for ; Tue, 17 Jun 2014 23:42:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:mailing-list:precedence:list-id :list-unsubscribe:list-archive:list-post:list-help:sender :delivered-to:mime-version:in-reply-to:references:date:message-id :subject:from:to:cc:x-original-sender :x-original-authentication-results:content-type; bh=h4xhpNNiYuIgvbe/6PRdsdDQYEuy8Lkc7L+fzANUXHw=; b=Gy+zK9jkymujtp2gAu7sNu4LLWoufqtQh47hMMEFBrUji9s9+/YNZ06j+KkmXCUL3E XiDqNOPpAUJKb0y8qdG+2OtqEZ591DdnxlqZNLEHVPZhPp8ngbjNBleTjAeOnkiftTHb D7uCUf/mojJAoFzFQJEfZd6a69WHisdEkF/cZgTyhUgMa8Po4o3+QVHMetkj7GbJM29m ytB0yEcy8yshD2juq8svA+4niE6DJ1Iaa9IrI0fCVOnz6uLUjqxgZFy29GjPcwagncR7 v4MCqGhHRSfOF7BRY36vFlHhzdbQy05FcX6TfD7NmfpgTkJldR3Zjj1ysx4ryINRh+wK XLCQ== X-Gm-Message-State: ALoCoQk/tSsjoA2jfgYPEAOqFg2jQWBwXBI30n5lbW+qn57vQNQnqp2RMS7ldDoiIPhineEd+yA5 X-Received: by 10.66.169.231 with SMTP id ah7mr20900pac.40.1403073740694; Tue, 17 Jun 2014 23:42:20 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.89.104 with SMTP id u95ls5292483qgd.5.gmail; Tue, 17 Jun 2014 23:42:20 -0700 (PDT) X-Received: by 10.58.220.230 with SMTP id pz6mr3689vec.9.1403073740531; Tue, 17 Jun 2014 23:42:20 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [2607:f8b0:400c:c01::22a]) by mx.google.com with ESMTPS id jm9si434968vec.86.2014.06.17.23.42.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 23:42:20 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 2607:f8b0:400c:c01::22a as permitted sender) client-ip=2607:f8b0:400c:c01::22a; Received: by mail-ve0-f170.google.com with SMTP id i13so380658veh.29 for ; Tue, 17 Jun 2014 23:42:20 -0700 (PDT) X-Received: by 10.52.96.8 with SMTP id do8mr21469004vdb.4.1403073740392; Tue, 17 Jun 2014 23:42:20 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.221.54.6 with SMTP id vs6csp261111vcb; Tue, 17 Jun 2014 23:42:19 -0700 (PDT) X-Received: by 10.66.186.238 with SMTP id fn14mr37897548pac.135.1403073739235; Tue, 17 Jun 2014 23:42:19 -0700 (PDT) Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id wl6si1128560pab.29.2014.06.17.23.42.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jun 2014 23:42:19 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-return-370503-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Received: (qmail 19851 invoked by alias); 18 Jun 2014 06:42:07 -0000 Mailing-List: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org Precedence: list 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 Received: (qmail 19838 invoked by uid 89); 18 Jun 2014 06:42:07 -0000 X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-la0-f48.google.com Received: from mail-la0-f48.google.com (HELO mail-la0-f48.google.com) (209.85.215.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 18 Jun 2014 06:42:05 +0000 Received: by mail-la0-f48.google.com with SMTP id el20so183088lab.7 for ; Tue, 17 Jun 2014 23:42:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.12.103 with SMTP id x7mr62796lbb.36.1403073722121; Tue, 17 Jun 2014 23:42:02 -0700 (PDT) Received: by 10.112.13.36 with HTTP; Tue, 17 Jun 2014 23:42:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Jun 2014 14:42:02 +0800 Message-ID: Subject: Re: [PATCH, loop2_invariant, 2/2] Change heuristics for identical invariants From: Zhenqiang Chen To: Steven Bosscher Cc: "gcc-patches@gcc.gnu.org" , Jeff Law X-IsSubscribed: yes X-Original-Sender: zhenqiang.chen@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 2607:f8b0:400c:c01::22a as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org; dkim=pass header.i=@gcc.gnu.org X-Google-Group-Id: 836684582541 On 10 June 2014 19:16, Steven Bosscher wrote: > On Tue, Jun 10, 2014 at 11:23 AM, Zhenqiang Chen wrote: >> * loop-invariant.c (struct invariant): Add a new member: eqno; >> (find_identical_invariants): Update eqno; >> (create_new_invariant): Init eqno; >> (get_inv_cost): Compute comp_cost wiht eqno; >> (gain_for_invariant): Take spill cost into account. > > Look OK except ... > >> @@ -1243,7 +1256,13 @@ gain_for_invariant (struct invariant *inv, >> unsigned *regs_needed, >> + IRA_LOOP_RESERVED_REGS >> - ira_class_hard_regs_num[cl]; >> if (size_cost > 0) >> - return -1; >> + { >> + int spill_cost = target_spill_cost [speed] * (int) regs_needed[cl]; >> + if (comp_cost <= spill_cost) >> + return -1; >> + >> + return 2; >> + } >> else >> size_cost = 0; >> } > > ... why "return 2", instead of just falling through to "return > comp_cost - size_cost;"? Thanks for the comments. Updated. As your comments for the previous patch, I should also check the overlap between reg classes. So I change the logic to check spill cost. return; @@ -513,7 +517,12 @@ find_identical_invariants (invariant_htab_type eq, struct invariant *inv) mode = GET_MODE (expr); if (mode == VOIDmode) mode = GET_MODE (SET_DEST (set)); - inv->eqto = find_or_insert_inv (eq, expr, mode, inv)->invno; + + tmp = find_or_insert_inv (eq, expr, mode, inv); + inv->eqto = tmp->invno; + + if (tmp->invno != inv->invno && inv->always_executed) + tmp->eqno++; if (dump_file && inv->eqto != inv->invno) fprintf (dump_file, @@ -725,6 +734,10 @@ create_new_invariant (struct def *def, rtx insn, bitmap depends_on, inv->invno = invariants.length (); inv->eqto = ~0u; + + /* Itself. */ + inv->eqno = 1; + if (def) def->invno = inv->invno; invariants.safe_push (inv); @@ -1141,7 +1154,7 @@ get_inv_cost (struct invariant *inv, int *comp_cost, unsigned *regs_needed, if (!inv->cheap_address || inv->def->n_addr_uses < inv->def->n_uses) - (*comp_cost) += inv->cost; + (*comp_cost) += inv->cost * inv->eqno; #ifdef STACK_REGS { @@ -1249,7 +1262,7 @@ gain_for_invariant (struct invariant *inv, unsigned *regs_needed, unsigned *new_regs, unsigned regs_used, bool speed, bool call_p) { - int comp_cost, size_cost; + int comp_cost, size_cost = 0; enum reg_class cl; int ret; @@ -1273,6 +1286,8 @@ gain_for_invariant (struct invariant *inv, unsigned *regs_needed, { int i; enum reg_class pressure_class; + int spill_cost = 0; + int base_cost = target_spill_cost [speed]; for (i = 0; i < ira_pressure_classes_num; i++) { @@ -1286,30 +1301,13 @@ gain_for_invariant (struct invariant *inv, unsigned *regs_needed, + LOOP_DATA (curr_loop)->max_reg_pressure[pressure_class] + IRA_LOOP_RESERVED_REGS > ira_class_hard_regs_num[pressure_class]) - break; + { + spill_cost += base_cost * (int) regs_needed[pressure_class]; + size_cost = -1; + } } - if (i < ira_pressure_classes_num) - /* There will be register pressure excess and we want not to - make this loop invariant motion. All loop invariants with - non-positive gains will be rejected in function - find_invariants_to_move. Therefore we return the negative - number here. - - One could think that this rejects also expensive loop - invariant motions and this will hurt code performance. - However numerous experiments with different heuristics - taking invariant cost into account did not confirm this - assumption. There are possible explanations for this - result: - o probably all expensive invariants were already moved out - of the loop by PRE and gimple invariant motion pass. - o expensive invariant execution will be hidden by insn - scheduling or OOO processor hardware because usually such - invariants have a lot of freedom to be executed - out-of-order. - Another reason for ignoring invariant cost vs spilling cost - heuristics is also in difficulties to evaluate accurately - spill cost at this stage. */ + if ((size_cost == -1) + && (comp_cost <= spill_cost)) return -1; else size_cost = 0; diff --git a/gcc/loop-invariant.c b/gcc/loop-invariant.c index 6e43b49..af0c95b 100644 --- a/gcc/loop-invariant.c +++ b/gcc/loop-invariant.c @@ -104,6 +104,9 @@ struct invariant /* The number of the invariant with the same value. */ unsigned eqto; + /* The number of invariants which eqto this. */ + unsigned eqno; + /* If we moved the invariant out of the loop, the register that contains its value. */ rtx reg; @@ -498,6 +501,7 @@ find_identical_invariants (invariant_htab_type eq, struct invariant *inv) struct invariant *dep; rtx expr, set; enum machine_mode mode; + struct invariant *tmp; if (inv->eqto != ~0u)