From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 8C8403858D28 for ; Thu, 16 Mar 2023 20:32:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8C8403858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-ed1-x52b.google.com with SMTP id o12so12491590edb.9 for ; Thu, 16 Mar 2023 13:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1678998768; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2TMpZRwCL+evovL18z73vKURbJXiHoBHDbTrnETv7TY=; b=doZ/oFA/C9+x+5AgXGFic38xtfMs/MmeJ5yNobIIgjuYsRp7kbFdxkEDJhRy1ns3LD CME7LlrcwAncCu0OZK0iZcw7k1iqk7VBoG9l/1opZAVCRlymiOhzFwl8nXrZc5TYH5lx nX98XF4rGgAXbEH+Falt8ECd/Z8a8otkgmNThQ+EbFJxlVBKiv7plwOh8BL0HQNh65XC FtAjAGdY4YE5vr6k3G34tNtPYByKaBnmVnzVK5kJfML3sKbWoliN5e3HLAsy0WwGvptH PJesilwEqfBogyRDaBI5NBVjNoMA+OgXPLCWFwkptIzdquP+FjQoMOZ5ImTJFHCuTItn qhwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678998768; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2TMpZRwCL+evovL18z73vKURbJXiHoBHDbTrnETv7TY=; b=iQc6/3tKBsinflOQ6eWIpCuJscLTRi4TaRHs7sJdZHafQXigtuXX6f4nSghXYKhlDT y1IiFvRCVq1H15z08MICGH7/s6oDAzO9s0dwjdOPUa5sXgbl6faHC/u0+uBhod9vKa+o jqOFddVqy7QWhVOvybP2ODCesHbSLurpN65ubnntApb3A9Nzm2LoeOQC4cexgZw/bXAR OsbQ1oFtCv2ziiAIqR8X/EJdpQsbAyuugbvE5vtsy7fjB9yGGJqeBMteF6LxYN+5c1sr b0TuuAQrs706ao0Xgz9j5LG+zCwLWMEdOLv5AdQbz5NoKI7dGa4ZF6XgawYovd1y+KMf 0PSw== X-Gm-Message-State: AO0yUKUNKIBvkWS3oG2JgpTjSTxoDA8AqUyfIDC5jDdB+MHqGmGQIzkm nfMcWe71NIOpJpYJf3uh4PIZOLsDYwZXg4X9yLzU4A== X-Google-Smtp-Source: AK7set/eJ8bnsLV05bvnS4zcFBdsTY5jzy0AehK3mwC93AUbHYDd0LVHGH6SdjMFajp1SdglPP9a4/7R6hxI9iBe8ao= X-Received: by 2002:a50:d797:0:b0:4c2:1a44:642e with SMTP id w23-20020a50d797000000b004c21a44642emr513625edi.5.1678998768055; Thu, 16 Mar 2023 13:32:48 -0700 (PDT) MIME-Version: 1.0 References: <20230316152706.2214124-1-manolis.tsamis@vrull.eu> In-Reply-To: From: Philipp Tomsich Date: Thu, 16 Mar 2023 21:32:37 +0100 Message-ID: Subject: Re: [PATCH v1] [RFC] Improve folding for comparisons with zero in tree-ssa-forwprop. To: Jeff Law Cc: Manolis Tsamis , gcc-patches@gcc.gnu.org, Richard Biener Content-Type: multipart/alternative; boundary="000000000000260b4105f70a5d4f" X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000260b4105f70a5d4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to add a bit more color on this one... It was originally observed (and isolated from) _ZN11xalanc_1_1027XalanReferenceCountedObject12addReferenceEPS0_ and reproduces both for AArch64 and RISC-V. The basic block (annotated with dynamic instructions executed and percentage of total dynamic instructions) looks as follows: > 0x0000000000511488 4589868875 0.4638% > _ZN11xalanc_1_1027XalanReferenceCountedObject12addReferenceEPS0_ > 4518 lw a4,8(a0) > 0017029b addiw t0,a4,1 > 00552423 sw t0,8(a0) > 4685 addi a3,zero,1 > 00d28363 beq t0,a3,6 # 0x51149a This change reduces the instruction count on RISC-V by one compressible instruction (2 bytes) and on AArch64 by one instruction (4 bytes). No execution time improvement (measured on Neoverse-N1) =E2=80=94 as would = be expected. --Philipp. On Thu, 16 Mar 2023 at 17:41, Jeff Law wrote: > > > On 3/16/23 09:27, Manolis Tsamis wrote: > > For this C testcase: > > > > void g(); > > void f(unsigned int *a) > > { > > if (++*a =3D=3D 1) > > g(); > > } > > > > GCC will currently emit a comparison with 1 by using the value > > of *a after the increment. This can be improved by comparing > > against 0 and using the value before the increment. As a result > > there is a potentially shorter dependancy chain (no need to wait > > for the result of +1) and on targets with compare zero instructions > > the generated code is one instruction shorter. > > > > Example from Aarch64: > > > > Before > > ldr w1, [x0] > > add w1, w1, 1 > > str w1, [x0] > > cmp w1, 1 > > beq .L4 > > ret > > > > After > > ldr w1, [x0] > > add w2, w1, 1 > > str w2, [x0] > > cbz w1, .L4 > > ret > > > > gcc/ChangeLog: > > > > * tree-ssa-forwprop.cc (combine_cond_expr_cond): > > (forward_propagate_into_comparison_1): Optimize > > for zero comparisons. > Deferring to gcc-14. Though I'm generally supportive of normalizing to > a comparison against zero when we safely can :-) > > jeff > --000000000000260b4105f70a5d4f--