From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53888 invoked by alias); 29 May 2019 20:05:23 -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 53880 invoked by uid 89); 29 May 2019 20:05:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= 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 ESMTP; Wed, 29 May 2019 20:05:22 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CD4993154860; Wed, 29 May 2019 20:05:10 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-2.rdu2.redhat.com [10.10.112.2]) by smtp.corp.redhat.com (Postfix) with ESMTP id E651C60565; Wed, 29 May 2019 20:05:05 +0000 (UTC) Subject: Re: [PATCH] A jump threading opportunity for condition branch To: Jiufu Guo , gcc-patches@gcc.gnu.org Cc: jakub@redhat.com, rguenther@suse.de, dberlin@dberlin.org, segher@kernel.crashing.org, wschmidt@linux.ibm.com References: <1558446288-52444-1-git-send-email-guojiufu@linux.ibm.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <99bd2f87-7083-1129-1c68-4b2f98d1026a@redhat.com> Date: Wed, 29 May 2019 20:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <1558446288-52444-1-git-send-email-guojiufu@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg01963.txt.bz2 On 5/21/19 7:44 AM, Jiufu Guo wrote: > Hi, > > This patch implements a new opportunity of jump threading for PR77820. > In this optimization, conditional jumps are merged with unconditional jump. > And then moving CMP result to GPR is eliminated. > > It looks like below: > > > p0 = a CMP b > goto ; > > > p1 = c CMP d > goto ; > > > # phi = PHI > if (phi != 0) goto ; else goto ; > > Could be transformed to: > > > p0 = a CMP b > if (p0 != 0) goto ; else goto ; > > > p1 = c CMP d > if (p1 != 0) goto ; else goto ; A few high level notes. I think LLVM does this in their jump threading pass as well, mostly because it enables discovering additional jump threading opportunities IIRC. But it appears to me to be inherently good on its own as well as it eliminates a dynamic unconditional jump. It's also the case that after this transformation we may be able to combine the assignment and test resulting in something like this: > > if (a CMP b) goto ; else goto ; > > > if (c CMP d) goto ; else goto ; Which is inherently good *and* the blocks no longer have side effects which can have secondary positive effects in the jump threader. I wouldn't be surprised if this was particularly useful for chained boolean logical tests where some of the arms collapse down to single tests. Jeff