From patchwork Wed Dec 2 16:27:02 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 551453 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 893CC140320 for ; Thu, 3 Dec 2015 03:27:35 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=Ei1dfdo2; 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:to :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=CM0tFFBdbmvcQmvDDx/R03MMB7cwgUs46loztYE7kY9MqdqJIc 3Y0PFrEcOyTPYCpBEuN2Q56hyammmH3AuxU1kMgQa/wrpDWk6hMzFvSjetSNzk4U 0q3eH0MX5TPH8WTUXbPD2slWWtlU+3rZnyJXmNju4EnvvnXn8cxK+9Heg= 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:to :from:subject:message-id:date:mime-version:content-type; s= default; bh=noAl1yTYoy0rKfQSZdpSY+jebwc=; b=Ei1dfdo2v/jX3sA07IJO 0kcgo1v+qkvs4W7Z635rSOoQVu7eQ9MU/fC3VS0CLLHaqUd1ZrV0wMGTT2G5eJ0k AZ6zSzCjBreshrH+PK2Ai1B4wUL9YVYLsodv0uydZKLG1Kqvz+VAz6E+CtEwqMMV daTFZrHTkjOHOO3tDuAEdQM= Received: (qmail 7169 invoked by alias); 2 Dec 2015 16:27:07 -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 7073 invoked by uid 89); 2 Dec 2015 16:27:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 02 Dec 2015 16:27:04 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id ED9128A167 for ; Wed, 2 Dec 2015 16:27:02 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-91.phx2.redhat.com [10.3.113.91]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tB2GR2C3022254 for ; Wed, 2 Dec 2015 11:27:02 -0500 To: gcc-patches@gcc.gnu.org From: Jeff Law Subject: [RFA] [PR tree-optimization/68599] Avoid over-zealous optimization with -funsafe-loop-optimizations Message-ID: <565F1BD6.7080402@redhat.com> Date: Wed, 2 Dec 2015 09:27:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 X-IsSubscribed: yes I strongly recommend reading the analysis in pr45122 since pr68599 uses the same testcase and just triggers the same bug in the RTL optimizers instead of the tree optimziers. As noted in 45122, with -funsafe-loop-optimizations, we may exit the loop an iteration too early. The loop in question is finite and the counter does not overflow. Yet -funsafe-loop-optimizations munges it badly. As is noted in c#6 and patched in c#8, when there's more than one exit from the loop, simply discarding the assumptions for the trip count is "a bit too unsafe". Richi & Zdenek agreed that disabling the optimization when the loop has > 1 exit was the preferred approach. Alex's patch did just that, but only for the tree optimizers. This patch does essentially the same thing for the RTL loop optimizer. If the candidate loop has > 1 exit, then we don't allow -funsafe-loop-optimizations to drop the assumptions/infinite notes for the RTL loop. This required ensuring that LOOPS_HAVE_RECORDED_EXITS when initializing the loop optimizer. Bootstrapped and regression tested on x86_64-linux-gnu and powerpc64-linux-gnu. For the latter, pr45122.c flips to a pass. Given this is covered by the pr45122 testcase, I didn't add a new one. OK for the trunk? Jeff diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 9a78b7a..ed677ec 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,12 @@ +2015-12-02 Jeff Law + + PR tree-optimization/68599 + * loop-init.c (rtl_loop_init): Set LOOPS_HAVE_RECORDED_EXITS + in call to loop_optimizer_init. + * loop-iv.c (get_simple_loop_desc): Only allow unsafe loop + optimization to drop the assumptions/infinite notations if + the loop has a single exit. + 2015-12-01 Andreas Tobler * config/rs6000/freebsd64.h (ELFv2_ABI_CHECK): Add new macro. diff --git a/gcc/loop-init.c b/gcc/loop-init.c index e32c94a..120316d 100644 --- a/gcc/loop-init.c +++ b/gcc/loop-init.c @@ -395,7 +395,7 @@ rtl_loop_init (void) dump_flow_info (dump_file, dump_flags); } - loop_optimizer_init (LOOPS_NORMAL); + loop_optimizer_init (LOOPS_NORMAL | LOOPS_HAVE_RECORDED_EXITS); return 0; } diff --git a/gcc/loop-iv.c b/gcc/loop-iv.c index c7d5164..dfa3ca3 100644 --- a/gcc/loop-iv.c +++ b/gcc/loop-iv.c @@ -3054,7 +3054,7 @@ get_simple_loop_desc (struct loop *loop) } } - if (flag_unsafe_loop_optimizations) + if (flag_unsafe_loop_optimizations && single_exit (loop)) { desc->assumptions = NULL_RTX; desc->infinite = NULL_RTX;