From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21580 invoked by alias); 2 Oct 2015 16:25:25 -0000 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 Received: (qmail 21571 invoked by uid 89); 2 Oct 2015 16:25:25 -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; Fri, 02 Oct 2015 16:25:24 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id C7BC62FE848; Fri, 2 Oct 2015 16:25:22 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-105.phx2.redhat.com [10.3.113.105]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t92GPMGB026680; Fri, 2 Oct 2015 12:25:22 -0400 Subject: Re: [PATCH] Improve DOM's optimization of control statements To: Renlin Li , "gcc-patches@gcc.gnu.org" References: <560C45EE.10202@redhat.com> <560E6759.3020806@arm.com> Cc: Marcus Shawcroft From: Jeff Law Message-ID: <560EAFF1.60600@redhat.com> Date: Fri, 02 Oct 2015 16:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <560E6759.3020806@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00244.txt.bz2 On 10/02/2015 05:15 AM, Renlin Li wrote: > Hi Jeff, > > Your patch causes an ICE regression. > The test case is " gcc.c-torture/compile/pr27087.c", I observed it on > aarch64-none-elf target when compiling the test case with '-Os' flag. > > A quick check shows, the cfg has been changed, but the loop information > is not updated. Thus the information about the number of basic block in > a loop is not reliable. > > Could you please have a look? Appears to be pretty simple. If we collapse a conditional inside a loop, then we need to set the loop state as needing fixups. In this specific case we have a conditional where one path eventually leads back to the loop latch block, the other path exits the loop. We statically determine the conditional will always take us to the loop exit. That has the side effect of making the block with the collapsed conditional no longer part of the loop, it's actually part of the exit path. That changes the number of nodes in the loop, what edge(s) are the exit path(s) and possibly other stuff. I'm running a fix through testing now. Thanks, jeff