From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omggw0004-vm1.mail.otm.yahoo.co.jp (omggw0004-vm1.mail.otm.yahoo.co.jp [182.22.18.101]) by sourceware.org (Postfix) with ESMTPS id 157A13858D28 for ; Wed, 6 Sep 2023 04:24:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 157A13858D28 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=yahoo.co.jp Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.co.jp X-YMail-OSG: BzCvUcEVM1k11q1qCviGlUZ6Tk_yRCWDqRWc7gIsjbiZaMFYEAvHyU9rnXznEyc _dlXf38Pqa87bKEI06brXJYoZQDJoPO5E1sY2spBs7qDfFaoZLnp5biY2fq9Sx4qYe91Rn9q3_Bd 2Ma7pYXNy0gk5sq49jnXHxHzb3I27z7IssW5sxPfzi_SLjL3_FjzsjEfF4llE11bbE5lRLJCZmzZ QoC7TTZCM_iUFD7LSMD8UycEfqUiugx_tuRXmgQJ2mfZIFMLPMcRilNugDm0J1nCtDoXNTBXls0X 8CjBCYJEEZ2YSAWs7PLyOqlNXikRHqMOQrAcMLsFsI.ihygMf3HpAAFjo.qOo_cdgJl_7rEjxmSM lS3EdWNmp5G2wvO4RP4FPyllLkbIFBDo67.KwTVhZsF6hL0cR5mOcVWDr5U1u._FD0Q0hhNYYh_S WLP1Ad9zbyWHqXoUZuW18pRqTSheVHjx0RNjxvtd_Kh3CfNL7s0tzvkBZQdTFwiIR3cBA97cvkkv y1rf0M8Ly.QwewQbAUU98MRe58KNA1Mn0LcdApHWOmh5Ppfpbc1Qm2qL1N2UC_H6SA7W_WO3T.cv 4ELoXn1ktbjsyHZYFRShtfG2WX4jyx65VzxBZvpR1RBOpR3ZajMGqv7.rhhS64IlOibt4WakeFox KMXkKiq2TmXCtzlK1pAfHsEvv3mvg6rRWppSrD26qcA6zGj4zyI6zq7zmWATUCAMcS4s_TdGJiZ0 pqn3_cR_i_HC6mwo2nGDwSNw0iF0IraqYAS1NSm6oWafX5J7.zu7hr7LB_c.rnU0DmyXeI0uWgCN 4anKFiiy4O8hAgo5uxWeZcUJiAjuCzzRyIXPPifMDjWyMPn2wpQO7f4St23nB4VSiFXu3Rz7mRoT Pn7pJfRapGZeOum4V2xl4Gmzvpan9pVwOcY2oe08PIMN0cNIfm04wHBeUfOO5BOftqzQwEkD5tIe CvMI.rzcK8oYYp9sA3OMFZODb2WEj3hMfRG3HQaVVQ8xN1LSTxl_Ne0lENPfRYIIy72jJX2TjTu7 SZQDb Received: from sonicgw.mail.yahoo.co.jp by sonicconh6002.mail.ssk.yahoo.co.jp with HTTP; Wed, 6 Sep 2023 04:24:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1693974277; s=yj20110701; d=yahoo.co.jp; h=Message-ID:Date:MIME-Version:Subject:To:References:From:Cc:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=AXeuySFd9XjKTZ3nxamwpfYqGLwPQsAO0qBW5ddDWjs=; b=NsfdHKFNxJZ175OhxKC5j2O3VzWcnEUbFSa1Hb1KbkrDsv8YrTdP+04yIq/Ibb+Z f1RcIHSSM+wjoHzLCKwNyzRbA4vbJ7MCGAXWhzzkaA9J+dFvaZ8PgO4Z4G1sD6FDbG0 0hatlecrBxEYeYSiUVVSt3RU8gq2Mq+lgRhx0rQk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:Date:MIME-Version:References:From:Cc:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Lhd/WPzx+P1JpC9ATY8TFUNTo716Bap7mFgwXQss4mYxSOtqPEMUhg95Wd94P7NN skGeRTXefkUeYTO68WAq64kl1clYsIynftldftCtsf+24BQevDd5zHINQr/o+ttaf51 SlRo3frsiCGG2uotPiRun6DJ65HkI0/HELezuk5s=; Received: by smtphe6004.mail.ssk.ynwp.yahoo.co.jp (YJ Hermes SMTP Server) with ESMTPA ID 90090a177c486e03e09658b583490c19; Wed, 06 Sep 2023 13:24:37 +0900 (JST) Message-ID: <8888cd4e-8168-5065-af35-5096aa24f37f@yahoo.co.jp> Date: Wed, 6 Sep 2023 13:24:36 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH] xtensa: Optimize boolean evaluation when SImode EQ/NE to zero if TARGET_MINMAX To: Max Filippov References: <0164dc5a-35a7-2848-8153-5016f7582576.ref@yahoo.co.jp> <0164dc5a-35a7-2848-8153-5016f7582576@yahoo.co.jp> From: Takayuki 'January June' Suwa Cc: GCC Patches In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_DMARC_STATUS,NICE_REPLY_A,NML_ADSP_CUSTOM_MED,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: On 2023/09/06 8:01, Max Filippov wrote: > Hi Suwa-san, Hi! > > On Tue, Sep 5, 2023 at 2:29 AM Takayuki 'January June' Suwa > wrote: >> >> This patch optimizes the boolean evaluation for equality to 0 in SImode >> using the MINU (Minimum Value Unsigned) machine instruction available >> when TARGET_MINMAX is configured, for example, (x != 0) to MINU(x, 1) >> and (x == 0) to (MINU(x, 1) ^ 1). >> >> /* example */ >> int test0(int x) { >> return x == 0; >> } >> int test1(int x) { >> return x != 0; >> } >> >> ;; before >> test0: >> mov.n a10, a2 >> movi.n a9, 1 >> movi.n a2, 0 >> moveqz a2, a9, a10 >> ret.n >> test1: >> mov.n a10, a2 >> movi.n a9, 1 >> movi.n a2, 0 >> movnez a2, a9, a10 >> ret.n >> >> ;; after (prereq. TARGET_MINMAX) >> test0: >> movi.n a9, 1 >> minu a2, a2, a9 >> xor a2, a2, a9 >> ret.n > > ISTM that test0 could be done with movnez in the same three instructions: > > movi a9, 1 > movnez a2, a9, a2 > xor a2, a2, a9 Unfortunately, the MOV[EQ/NE]Z machine instruction can only be used to implement the functionality if the input and output physical registers are the same (a2 in the example). In fact, when modified to use MOV[EQ/NE]Z, GCC register allocator often prepends a register move instruction to satisfy the above constraint (and thus often does not save instruction count). I'm currently trying to see if I can somehow follow up after the physical register is determined (around split2 or peephole2). > >> test1: >> movi.n a9, 1 >> minu a2, a2, a9 >> ret.n > > ISTM that test1 could be done with movnez in the same two instructions: > > movi a9, 1 > movnez a2, a9, a2 >