From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by sourceware.org (Postfix) with ESMTPS id 5D9523858D32 for ; Mon, 2 Jan 2023 16:20:36 +0000 (GMT) Received: by mail-pl1-x62a.google.com with SMTP id m4so29971748pls.4 for ; Mon, 02 Jan 2023 08:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=vg/ijynVC+CpbmYTg5sV66Y02qIDzDuRoePudTokyOE=; b=P5GEGS7u1oKo70EL4P0fAiBU3qxAuLmNLBWxc/YfWJDZJ97jlp5TnNjMFSzOv4ArfN Lsqot0tTDxICOKoCewENFDJzmb+JCyxO/Pn4tSPOwc3xX2dYBdNw+nC6ihyYQB67AOrC XkCaLoIOha9RmJ1zWFeNoCz9ulpe2KSN5UQU1PSEot0rFZ6x1Hv6Tfm73bcE5dOIPa94 Z4MwZfRIygMzazZTxXLiNVMDa97dheykxW6eKV9KN7ZW3WDp9+/8ocRjuWJ/fzKFRYdU xCg6B/+WlceMW4zvnr2N87uk4nw672gTGZrUgPEYV2gwuYpxowPRgylXGfAt+ElvFvh8 Gugw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vg/ijynVC+CpbmYTg5sV66Y02qIDzDuRoePudTokyOE=; b=EinmZH7H1B7zycRi8otNwsvLAy+qP7PG1z604TGvJ2YIhLvrtIiCahZfIWIqR8kdi9 99B0d/uhJ8ixRw46Cx/W2QSCFVr1AIbauQ+G/zmjQAyBIsEy1jmTu17alVOoihjW6n1a N+oxv525tT6lfWsf2d2IkLyH63h7uKFR8vO+IbxHRgLHRnzWFdWZhfZhBC0lZ/a2FOes Ld54n3vf8CSBnGXIx9ry9iFs1k1zE0YzgP2XY7CkK570qZkKBuq/+dy53crABq9aTm84 Nij7pJ5s2/A9BAIQJWuG1Z9mYe4pmfGxX5FfPrFxjkk9zo/P6cw5l7WiSLwLV3LLV0lX hHFw== X-Gm-Message-State: AFqh2koE0IdnTwQtatj+kcxV3J9msG8pouJHt1lp0UDbmo2NITnvA86y K3Nu3JYrvLQEohfjpABT1gk= X-Google-Smtp-Source: AMrXdXv8/MRAbv6qYI/blY+PIhYrnM2P7tOi+nhXv79IPlC55AX1Y2SAKRO7BRLYkpmmAzjnZAUcEQ== X-Received: by 2002:a17:90a:bc8a:b0:225:f216:b421 with SMTP id x10-20020a17090abc8a00b00225f216b421mr26838947pjr.6.1672676435079; Mon, 02 Jan 2023 08:20:35 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id t23-20020a17090ad15700b00218abadb6a8sm17201380pjw.49.2023.01.02.08.20.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jan 2023 08:20:34 -0800 (PST) Message-ID: <06fc4f7f-264c-7955-96a1-6e51be401818@gmail.com> Date: Mon, 2 Jan 2023 09:20:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH] Fix RTL simplifications of FFS, POPCOUNT and PARITY. Content-Language: en-US To: Jakub Jelinek Cc: Roger Sayle , 'GCC Patches' , 'Segher Boessenkool' References: <002e01d91df9$79df2670$6d9d7350$@nextmovesoftware.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 1/2/23 08:59, Jakub Jelinek wrote: > On Mon, Jan 02, 2023 at 08:45:15AM -0700, Jeff Law via Gcc-patches wrote: >> On 1/1/23 08:55, Roger Sayle wrote: >>> In 2011, the rtl.texi documentation was updated to reflect that the >>> modes of the RTX unary operations FFS, POPCOUNT and PARITY must >>> match those of their operands. Unfortunately, some of the transformations >>> in simplify-rtx.cc predate this tightening of RTL semantics, and have >>> not (until now) been updated/fixed. i.e. The POPCOUNT and PARITY >>> optimizations were "correct" when I originally added them back in 2007. >>> >>> Segher requested that I split this piece out from a fix for PR 106594 in >>> https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601501.html >>> >>> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap >>> and make -k check, both with and without --target_board=unix{-m32}, >>> with no new failures. Ok for mainline? >>> >>> >>> 2023-01-01 Roger Sayle >>> >>> gcc/ChangeLog >>> * gcc/simplify-rtx.cc (simplify_unary_operation_1) : >>> Avoid generating FFS with mismatched operand and result modes, by >>> using an explicit SIGN_EXTEND/ZERO_EXTEND instead. >>> : Likewise, for POPCOUNT of ZERO_EXTEND. >>> : Likewise, for PARITY of {ZERO,SIGN}_EXTEND. >> ?!? The docs still seem to indicate to me that the modes of the input and >> output operands can differ. Let's take PARITY as an example: > > See the PR50161 thread in > https://gcc.gnu.org/legacy-ml/gcc-patches/2011-08/threads.html#01847 > The options are to disallow different modes, which is what my patch did > (perhaps not all documentation has been tweaked), or ensure that the operand > of those is never constant. The latter is much harder and needs to be done > in many places. While for SUBREG/ZERO_EXTEND/SIGN_EXTEND and to some extend > also FLOAT/UNSIGNED_FLOAT we already try hard not to fold those immediately > (and still find every now and then spots where we don't do that), for the > rarely used unary rtls we certainly don't. Sigh. Lack of modes on constants mucking things up elsewhere. There's no good reason other than our poor representation to force the input and output modes to match for these instructions. > >> In fact Raphael and I were about to submit a patch which takes advantage of >> that capability to improve the code slightly for risc-v. > > Just use a pattern with zero_extend or sign_extend around it or subreg of > it? If it were only that easy ;( In the bowels of the simplifications the zero_extension turns into either a pair of shifts or an AND with a mask (I forget which offhand). I'm sure we *can* work around this in the target, but it'll be ugly. The documentation definitely needs to be updated. I looked at the whole family a few weeks ago and my recollection was they all need to be fixed (ffs, clrsb, clz, ctz, popcount & parity) if the defined semantics are that the input and output operand modes must match. Jeff