From patchwork Mon Jun 14 00:30:50 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 1491515 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=qyBnLtRf; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4G3C7124tMz9sW4 for ; Mon, 14 Jun 2021 10:31:23 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id ADB2C3896C0B for ; Mon, 14 Jun 2021 00:31:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ADB2C3896C0B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1623630680; bh=3hwRe2k5u2vhtIgbME5YQsM/lyXpMFPnuKJhtCFB8bA=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=qyBnLtRf1z+a9vyOZIGJEkoU/CBq536bz61a0Sf/BfxBMBLqccCuXNzVRSGZq0sxl llG4WhC4CWoizN/MiOhv1xsdrdD8ZHum+G+2QU4OHD0qJLypru4SamP3cvp1p8mtEb 10YJi0LHv3OrrtUSlr0XRNFYL25WNTpeZi/AB0xY= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id DB0BE385DC33 for ; Mon, 14 Jun 2021 00:30:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DB0BE385DC33 Received: by mail-pl1-x62d.google.com with SMTP id 69so5653989plc.5 for ; Sun, 13 Jun 2021 17:30:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language; bh=3hwRe2k5u2vhtIgbME5YQsM/lyXpMFPnuKJhtCFB8bA=; b=pqVfecsY8b47gy5XMrN5xc7CWYUMFQCM2Scv5Zgfwx+a9OBFxZy5LHWu/linYT2ssX QoJq4ysQv/j8cfhaUxt/U0PsXyJM+nXft38bJzC+U3SWwrm/PAlHBoGJlXC50sps5Z5w yiB5bYvYmMCXAcdC3rmxEvx54VuhVcGGsMPQy75xQRiMOyXc2zC9KqFnFx602ILqEDmp LizUteCwylnMjlaJn0f5l72mSIHapoeL38CLorSpcGbAaVEWNjO37NYvjEw1Ko8whgJm mLEm2wOzbC7/rnBhdUjX9TvSkgOgs34UP0qERHBXjSFYWtwVqnxuQuRPnovpQolDd9Up XGlg== X-Gm-Message-State: AOAM531+QthaOpy4n55D1p8JZRG4f1fiz3DE969K7zyh6LIQceD1olRo UvfpGiPzzv0G+AH6pPDXS3k/L2k/RfxFVA== X-Google-Smtp-Source: ABdhPJyrDEdryK48zgGo92UDhYNn+ShGWtFvNlr6YxNPRe+lfBzakOCDZZezXzf0l9l5vFL2RAbNMQ== X-Received: by 2002:a17:90b:1808:: with SMTP id lw8mr15789802pjb.30.1623630653498; Sun, 13 Jun 2021 17:30:53 -0700 (PDT) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id kb14sm8776473pjb.2.2021.06.13.17.30.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Jun 2021 17:30:53 -0700 (PDT) To: GCC Patches Subject: [RFA] Minor improvement to compare elimination Message-ID: Date: Sun, 13 Jun 2021 18:30:50 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 Content-Language: en-US X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Jeff Law via Gcc-patches From: Jeff Law Reply-To: Jeff Law Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" I was reviewing the generated code in libgcc for the H8 to see if there were any obvious redundant test/compares.  Sure enough I found one in the first file I looked at ;-) So after IRA we have something like this: (insn 43 112 44 4 (set (subreg:SI (reg:DI 40) 0)         (and:SI (subreg:SI (reg:DI 38) 0)             (subreg:SI (reg:DI 39) 0))) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 246 {*logicalsi3}      (nil)) (insn 44 43 47 4 (set (subreg:SI (reg:DI 40) 4)         (and:SI (subreg:SI (reg:DI 38) 4)             (subreg:SI (reg:DI 39) 4))) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 246 {*logicalsi3}      (expr_list:REG_DEAD (reg:DI 39)         (expr_list:REG_DEAD (reg:DI 38)             (nil)))) (jump_insn 47 44 83 4 (set (pc)         (if_then_else (ge (subreg:SI (reg:DI 40) 0)                 (const_int 0 [0]))             (label_ref 55)             (pc))) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 281 {*branch}      (expr_list:REG_DEAD (reg:DI 40)         (int_list:REG_BR_PROB 1073204964 (nil))) Which is just a DImode AND and a conditional branch based on the state of the most significant bit.  On the H8 we don't expose the condition codes until split2.  After splitting we have: (insn 228 227 229 4 (parallel [             (set (reg:SI 0 r0)                 (and:SI (reg:SI 0 r0)                     (reg:SI 2 r2)))             (clobber (reg:CC 12 cc))         ]) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 263 {*andsi3}      (nil)) (insn 229 228 230 4 (parallel [             (set (reg:SI 1 r1)                 (mem/c:SI (plus:SI (reg/f:SI 7 sp)                         (const_int 12 [0xc])) [1 %sfp+-12 S4 A32]))             (clobber (reg:CC 12 cc))         ]) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 20 {*movsi_clobber_flags}      (nil)) (insn 230 229 231 4 (parallel [             (set (reg:SI 1 r1)                 (and:SI (reg:SI 1 r1)                     (reg:SI 3 r3 [orig:39+4 ] [39])))             (clobber (reg:CC 12 cc))         ]) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 263 {*andsi3}      (nil)) (insn 231 230 232 4 (set (reg:CC 12 cc)         (compare:CC (reg:SI 0 r0)             (const_int 0 [0]))) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 131 {cmpsi}      (nil)) (jump_insn 232 231 83 4 (set (pc)         (if_then_else (ge (reg:CC 12 cc)                 (const_int 0 [0]))             (label_ref 55)             (pc))) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 283 {*branch_1} So far so good.  An astute observer would probably note at this time that insn 228 is a good candidate to eliminate the compare at insn 231, except that insns 229 and 230 clobber the condition codes. Things stay effectively like this through compare elimination which fails to trigger because the condition codes are clobbered between insn 228 and insn 231. *But* it turns out that insn 229 and insn 230 are both dead. They'll be detected as such during peephole2, but that's too late to help compare elimination (and in case you're wondering the DImode use in insn 47 keeps insn 44 from being deleted as dead before reload). Naturally once peep2 has deleted the dead code it becomes obvious there's a redundant test/compare. The fix here is trivial -- just ask the DF machinery to do a fast DCE from compare-elimination.  That kills the two problematical insns and then allows compare-elimination to detect that the compare is not necessary.  This shows up numerous times throughout libgcc and newlib.  Each time we're able to eliminate a compare like this we save 6 bytes of instruction space and 3 cycles. *** orig.s      2021-06-13 20:21:55.014435803 -0400 --- new.s       2021-06-13 20:21:34.329494744 -0400 *************** ___absvdi2: *** 43,50 ****         not.l   er2         mov.l   @(8,er7),er0         and.l   er2,er0 !       cmp.l   #0,er0 !       bge     .L2         sub.l   er0,er0         mov.l   er0,@(16,er7)         sub.l   er1,er1 --- 43,49 ----         not.l   er2         mov.l   @(8,er7),er0         and.l   er2,er0 !       bpl     .L2         sub.l   er0,er0         mov.l   er0,@(16,er7)         sub.l   er1,er1 I've bootstrapped and regression tested this on x86_64, though I doubt it makes any difference there.  BUt I'd bet it would help other targets that don't expose double-word operations and have a condition code that is clobbered by most instructions. OK for the trunk? Jeff Minor improvement to compare elimination gcc/ * compare-elim.c (try_eliminate_compare): Run DCE to clean things before eliminating comparisons. diff --git a/gcc/compare-elim.c b/gcc/compare-elim.c index 85085cd6973..607eadc3d96 100644 --- a/gcc/compare-elim.c +++ b/gcc/compare-elim.c @@ -906,6 +906,7 @@ try_eliminate_compare (struct comparison *cmp) static unsigned int execute_compare_elim_after_reload (void) { + df_set_flags (DF_LR_RUN_DCE); df_analyze (); gcc_checking_assert (!all_compares.exists ());