From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by sourceware.org (Postfix) with ESMTPS id E335E3858C41 for ; Fri, 19 May 2023 22:04:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E335E3858C41 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-25332b3915bso2990840a91.2 for ; Fri, 19 May 2023 15:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684533883; x=1687125883; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LXrkrNZt3Q56vLGhfRDK+I3kcyB7566k6QSATf8CELQ=; b=lPCqg89CkhLxY7c+HdPS5uN2k3lFiYN4koKvMrif9/ztyhv3ywWtgstBdgJns2VI5i 7iiwP8KP6UpaEfaXdRgz+lcH6QC904ps3FhCRTwTFHlTEZ21fLro3yzg7hsVWVUbKJhk 0PeEgz0qkvPqA2K51pxR5aiMvVRMoIaVOc448xzmO306+Jp5BqJZcbgJcONTcrExY71d orM1iN3I5bXmOEPbN6XZk9Aj+MuZkbb80HrUiKqTvkFrJDCFVWZyOUQio+vuuOSkJaaO jrTwdPflhZQajvKmBuhGiBdX/XKHGS7d0UHW1mQoLPONqCNwmbN0v8v0WuXkETEgSxqH oaHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684533883; x=1687125883; h=content-transfer-encoding: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=LXrkrNZt3Q56vLGhfRDK+I3kcyB7566k6QSATf8CELQ=; b=PrvV+WG0ZWHT8tGjDwz9IVCJWYqEgnj3CgP+xdUzDLgUp8X21y6gK/cbKoG7lHUEfM MnJPU2fsLkQWC8onaUILOwSMMFhj4LhNrcPoNDhEQ+oCFFElY4u5YJOS4GLPkh3M1CLv oUZv0NVIyDegr+0sRgjF8QxHL85flWhqiTu+fWmFUsmx7czMf6R1b4xdWM9A6IPxNbKF +caQd5EV6DKosq4Pem0kQf2He01Dc8QEOoa+7GmpsyeAiOw3yqixDRYdUFK8eGAH+pYi xKTA9p8+4LscuGlA//vA8+GUBGJ3bFVL6GkpephNxF96oU/F3NKEbGIkYfTQjLLf38+S XT7Q== X-Gm-Message-State: AC+VfDxGvcmJUFb5c4O7VsVVHHe+XeefmsFyErw3ky/gaMcOovziizMG emgpzv1el7X9hCdSQwEicKnCD9/c0/LEtDDAUzM= X-Google-Smtp-Source: ACHHUZ46IR1o8Zdsk7ik+E7oL2Ppi182byp6n4C+g/6F01Qs/77OQJ7uM3ZYro5jEHa2XdyR0gy6YXvRpEZiqhH24Dw= X-Received: by 2002:a17:90b:a45:b0:253:947f:af51 with SMTP id gw5-20020a17090b0a4500b00253947faf51mr1653001pjb.5.1684533882736; Fri, 19 May 2023 15:04:42 -0700 (PDT) MIME-Version: 1.0 References: <20230519021410.1841811-1-apinski@marvell.com> <128a9b18-5598-cddf-94cd-a98f03dc851b@gmail.com> In-Reply-To: <128a9b18-5598-cddf-94cd-a98f03dc851b@gmail.com> From: Andrew Pinski Date: Fri, 19 May 2023 15:04:30 -0700 Message-ID: Subject: Re: [PATCH 1/2] Improve do_store_flag for single bit comparison against 0 To: Jeff Law Cc: Andrew Pinski , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On Fri, May 19, 2023 at 9:40=E2=80=AFAM Jeff Law via Gcc-patches wrote: > > > > On 5/18/23 20:14, Andrew Pinski via Gcc-patches wrote: > > While working something else, I noticed we could improve > > the following function code generation: > > ``` > > unsigned f(unsigned t) > > { > > if (t & ~(1<<30)) __builtin_unreachable(); > > return t !=3D 0; > > } > > ``` > > Right know we just emit a comparison against 0 instead > > of just a shift right by 30. > > There is code in do_store_flag which already optimizes > > `(t & 1<<30) !=3D 0` to `(t >> 30) & 1`. This patch > > extends it to handle the case where we know t has a > > nonzero of just one bit set. > > > > OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. > > > > gcc/ChangeLog: > > > > * expr.cc (do_store_flag): Extend the one bit checking case > > to handle the case where we don't have an and but rather still > > one bit is known to be non-zero. > So as we touched on in IRC, the concern is targets where the cost of the > shift depends on the number of bits shifted. Can we look at costing > here to determine the initial RTL generation approach? > > Another approach that would work for some targets is a single bit > extract. In theory we should be discovering the extract idiom from the > shift+and form, but I'm always concerned that it's going to be missed > for one or more oddball reasons. I now have a patch set which does the extraction directly rather than havin= g combine try to combine it later on. This actually fixes an issue with avr t= arget which expands out the shift by doing a loop. Since we are using extract_bit_field, if a target does not have an extract pattern, it will expand using shift+and form instead. I will resubmit this and the other patch after this new patch set is comple= ted. Thanks, Andrew Pinski > > jeff >