From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 19C853858D32 for ; Mon, 2 Jan 2023 17:47:13 +0000 (GMT) Received: by mail-pj1-x1030.google.com with SMTP id n12so17680314pjp.1 for ; Mon, 02 Jan 2023 09:47:13 -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=UjXPIVa3GkzKzbMfpKP3gtjoWiGf9Ks0K74l2ElJC4U=; b=YkhwUs/ELSZU6zAFvl12ssgVTGC5kR17nbOvLe6z2likqdXXeYaHUlxE45SUXXIDEX Ch+Yjc7IThuzP6dmFM5gh+LtvV+mwfEw+wEzCORyl6YXciQEjZJ1saoVyzZoocL7vY54 LKVaioc3UhJhCZO13Pl1WtslHzUs5944RRwMUYtxqDbLBc6wcPEAvx15amckFR73+cK1 cFiurU65W8EMxxSaHvT80unKLsYaKU/HIoKW3v4O1DU/+FsGbjHKjSfKXaRdUANo/zGB UlDt8gySIS+Lg7oM3L18ESHIgdaK92zxUpKQznt1mv/EBwJqU/tPUEmCQ8q8RlabG8sC Dqaw== 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=UjXPIVa3GkzKzbMfpKP3gtjoWiGf9Ks0K74l2ElJC4U=; b=7dpB2BASOjY/ln8hbnPXfztJH214jhiIUaN/qW5aVEyLYcTIcgsN+QK1Nt1miCOl8c oKnrO3UmKESls6FgpGErrsyMefYAUAWz8JXboANCeuYDm8jnUFQXv4rQZUdtXB2eXmoo 83Ww0k9uDvIuc94oseZfyYQyp6aAWjjcRmRILX5DJxC8Vz7o5upyMM6qVfRlEuq3m7/Q J2QrB9norNBhkTVdJCu4CPyWylous2VaZCBpTn/FVepGIa+cjl18+gNK3/n19dwi1A8s zhof0uFmFPEqYaf3zXdnnFELE11kjJm9FdxwYw8aqOvu/7BA0hM1t21kaV6oehz9AhL8 EGVg== X-Gm-Message-State: AFqh2kpZlTQSlD/OkILqQ6xwOQcorudKPNBktpVMDj1SRi88NX7pYCMk TKfZaOUXz58/lh6FuNraCgY= X-Google-Smtp-Source: AMrXdXvkt5hxEKvWBB0tDNNMD3o++PrjzgspbICsazrE17AUm2u+nRKVKfM6mdZBFXZzSZZecBvY9w== X-Received: by 2002:a17:90a:7101:b0:225:af73:d2a6 with SMTP id h1-20020a17090a710100b00225af73d2a6mr42005100pjk.42.1672681631855; Mon, 02 Jan 2023 09:47:11 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id p13-20020a17090a748d00b00225e5686943sm13213585pjk.48.2023.01.02.09.47.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jan 2023 09:47:11 -0800 (PST) Message-ID: Date: Mon, 2 Jan 2023 10:47:10 -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: "roger@nextmovesoftware.com" Cc: GCC Patches 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 10:30, roger@nextmovesoftware.com wrote: > > Hi Jeff, > >> On 2 Jan 2023, at 15:45, Jeff Law 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: >> >>> @cindex @code{parity@var{m}2} instruction pattern >>> @item @samp{parity@var{m}2} >>> Store into operand 0 the parity of operand 1, i.e.@: the number of 1-bits >>> in operand 1 modulo 2. >>> @var{m} is either a scalar or vector integer mode. When it is a scalar, >>> operand 1 has mode @var{m} but operand 0 can have whatever scalar >>> integer mode is suitable for the target. >> >> The mode of the pattern name has to match the mode of the input operand. The mode of the >> output operand can differ from the mode of the input operand. we seem to have a disagreement >> on the documented semantics of these opcodes. > > The documentation that you're looking at is the definition of the parity optab in > md.texi, not the definition of the PARITY rtx in rtl.texi. The distinction is subtle. > Hence a backend can define paritysiqi2 but in the RTL pattern it expands to the > unary PARITY operator must have the same result type as its operand type, > wrapped in either a truncate or extension if necessary. Hmm, yea I was looking at md.texi, not rtl.texi. I'll take a look at the latter after I get some coffee. Thanks! jeff