From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 0BD3A3858D32 for ; Mon, 2 Jan 2023 15:45:18 +0000 (GMT) Received: by mail-pl1-x62b.google.com with SMTP id n4so29887262plp.1 for ; Mon, 02 Jan 2023 07:45:18 -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:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=DIT+UXsI/aqTHd56BaGFI/pigNNuOEkn2QH/ZuUIfW4=; b=YXAMntVduoamIHnc1R91+B4kx4KkYqNvMH3ED/KR9pGuHg/CB0vlrEtdk9zSEEu4Of D6Pgq1iIrSQ8bac9pTRVoRAiaCEKMbAJrpMF39BX5Zxg6IdM8X5soYttABgD/IZHNAp0 dLTsvPINHOBGIgzi/MAQswUx7NeiDSakbISwt8qBXC2hUKA46LXcJgbseNbk0br07L74 OJR0ChivAbvrC5BwczaT14nTHEm5jq3EHltMmvDHA7uIg8/xpRbqlreRMXJ26GGBrDfA BnyhDcowdqhNlcOadQGGyNg85VZqKLUO0gmRRDAN4vjVhdUbwR+CB5JhUYkEH78mcy67 6wRA== 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:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DIT+UXsI/aqTHd56BaGFI/pigNNuOEkn2QH/ZuUIfW4=; b=UEMc2g1cL8C1pS/rMDSfsb8frclLkPaDfywRL+tQo7iTFO4ejbbl6KxdAVUG6d30Nw Y1rNOLlBNqjGc9DLY/1yYBqb1Zgpq4oIlCNAGfmxjzvYYqoOBKjxy3hxCJCEwyOnu+1F Y8wRBdEQKvKD8fNE7HMUfK4EKiEsj8V7liRDbjuIsyYCZG76NezsItp9MApW/z6uSzqa sU3AjHUOFU1QTcox12W478xybFYyUHLGiVwVTsA+AUy0I7YVA+3sxfu4+isa6RjOZjb0 PULvSkqRmKihqXs6YTT8PaNkNSMzLuJ5X7mNqN4ZZAawBLxIGt1swGfLmr3N74yh1h/S WEwQ== X-Gm-Message-State: AFqh2kruAXjol9p7z/F9WRvJa/yDuw6da59HRABIZxXk5jis01WvHLaQ Y33Rkjtqk3w8guWkXOGnbLE= X-Google-Smtp-Source: AMrXdXuXeVbUSZsrCey40cr4ej83lbdCZxSYOvUcHDwHBsjJrTfLcYphKHkKeGKSZfa46CGyoX6VCw== X-Received: by 2002:a17:902:ce85:b0:18f:a0de:6ad0 with SMTP id f5-20020a170902ce8500b0018fa0de6ad0mr55936625plg.55.1672674316881; Mon, 02 Jan 2023 07:45:16 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id n10-20020a170902f60a00b00188fdae6e0esm4849544plg.44.2023.01.02.07.45.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jan 2023 07:45:16 -0800 (PST) Message-ID: Date: Mon, 2 Jan 2023 08:45:15 -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. To: Roger Sayle , 'GCC Patches' Cc: 'Segher Boessenkool' References: <002e01d91df9$79df2670$6d9d7350$@nextmovesoftware.com> Content-Language: en-US From: Jeff Law In-Reply-To: <002e01d91df9$79df2670$6d9d7350$@nextmovesoftware.com> 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/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. 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. Jeff