From patchwork Thu May 26 11:02:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 626637 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3rFmSJ2SfRz9t4P for ; Thu, 26 May 2016 21:02:07 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=ntsSczQT; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; q=dns; s= default; b=ZHfTyWe7WDuKJT5AFZqEIAtf1wYbuXt7VKmYWQsgurCwNx4yGCuCP TFw/FnHZNV8+P7YugNOsph2ZtOH8tAhSktgjWcp2B3Mbt0zEIuPEtnovFnuZPgYG H1kzuu4PH4LP6TYan3fmfZT/qsxg+bug/rHoSDwI6y7l7ZKn2mNbPo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; s= default; bh=ecGFQEo6Jao5Th3iPfzSQJjBLTw=; b=ntsSczQTX7fG5DDfIgR2 VNjD4gsrVCQF0SYn79JQ2gwMXU7Yh4UWZfP96nONylqNan8Zi//qakt413bMGrIX SEOb+LO600vcBq3UEEb0IQG6G35wM+7+/l4+MWOead6JNJxhlQs+LO9N7jbx+U8C 783HB3Zlh3PQfudnKqW4HZ8= Received: (qmail 94879 invoked by alias); 26 May 2016 11:01:59 -0000 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 Received: (qmail 94864 invoked by uid 89); 26 May 2016 11:01:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=ira X-HELO: mail-pf0-f195.google.com Received: from mail-pf0-f195.google.com (HELO mail-pf0-f195.google.com) (209.85.192.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 26 May 2016 11:01:54 +0000 Received: by mail-pf0-f195.google.com with SMTP id g132so1932759pfb.3 for ; Thu, 26 May 2016 04:01:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=Z3g+6O/5R+ueXa8Hb+PJniV+MgrG7FzkAxyrW3QX3U8=; b=TIWTduHuIVwRu6najCEcRbSCgNrxbnsiJK4CgomuFgVpu/0HGO7fayte1D59dXCUi7 LXMOB66/sQQUpwdFmhy1jihzsS57EfJ/Nc65KuY871jQkWqtyEbth/tIZ+1j1WnDJ/EI ov79urEC4+KV6BHq8dGnwk3JypGfDvTkyn9rHw6OxGH4nrYGjoTH+wEoxt6EBVnJEKfJ Yui6PX8wg6zZduOOmj+iMdhjfZ2pdbHnigCbt90MVYK14gIY+lIiSiaEXup4d5qj5jTL q3pLPa6kftaZXGK4Hyh9YpkMq0F+eYCAcH6mBJHbL+oawQfkgbU73X6Jwfx4MqnPmnoE Y8Dg== X-Gm-Message-State: ALyK8tLrC4wK7wT24/0NFj4QAo3z8GjAbWetq5+yF1vxW28sQPTuM6y4hNBXy1Os39Lphg== X-Received: by 10.98.102.205 with SMTP id s74mr10800094pfj.54.1464260512188; Thu, 26 May 2016 04:01:52 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-146-233.sa.bigpond.net.au. [58.160.146.233]) by smtp.gmail.com with ESMTPSA id az6sm19559909pab.43.2016.05.26.04.01.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 May 2016 04:01:51 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 36A5AEA0199; Thu, 26 May 2016 20:32:07 +0930 (ACST) Date: Thu, 26 May 2016 20:32:06 +0930 From: Alan Modra To: gcc-patches@gcc.gnu.org Subject: [PATCH] PR71275 ira.c bb_loop_depth Message-ID: <20160526110205.GJ3300@bubble.grove.modra.org> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes This fixes lack of bb_loop_depth info in some of the early parts of ira, which has been the case for quite some time. All active branches return 0 from bb_loop_depth() in update_equiv_regs, but whether that actually causes mis-optimization anywhere but trunk is yet to be determined. I played a little with trying to consolidate this loop_optimizer_init call with one that occurs a little later, but ran into ICEs. (We now have four calls to loop_optimizer_init in ira.c.) Bootstrapped and regression tested powerpc64le-linux and x86_64-linux. OK to apply? PR rtl-optimization/71275 * ira.c (ira): Call loop_optimizer_init to set up bb_loop_depth for update_equiv_regs and combine_and_move_insns. diff --git a/gcc/ira.c b/gcc/ira.c index 55b4bd7..1b269ea 100644 --- a/gcc/ira.c +++ b/gcc/ira.c @@ -5171,6 +5171,7 @@ ira (FILE *f) ira_set_pseudo_classes (true, ira_dump_file); init_alias_analysis (); + loop_optimizer_init (AVOID_CFG_MODIFICATIONS); reg_equiv = XCNEWVEC (struct equivalence, max_reg_num ()); update_equiv_regs (); @@ -5186,6 +5187,7 @@ ira (FILE *f) if (optimize) add_store_equivs (); + loop_optimizer_finalize (); end_alias_analysis (); free (reg_equiv);