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 34B423858D1E for ; Tue, 29 Nov 2022 04:52:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34B423858D1E 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-pl1-x62b.google.com with SMTP id jn7so12278193plb.13 for ; Mon, 28 Nov 2022 20:52:25 -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=O++cjIP/Yb6M/Fz+8+FUJaxmjT0kgwNBCs+xJSK/y7Y=; b=Az/tu7CH2kt+vzW9l1sYj6XwapJ3JtpxNsA2uUTWwt2ENU7k7U1e8AHNms2iPy5Y3x SISCfOknRaju6Xr+9T8ylVBL68DeVd/GCwJaUw7NEhEuX07qiTyz6kStnCh/YGdiQ2z9 0KTbn8Zbst5Rw0N8hEGr9PmL9taO7QX1GcSpJDD5QOgiQfSSX2zHpjC4sICG3LbuVoHI 76halxl7w+IhSFpGuUuSo1S9djYFyOXrFi7puDov80hNpK2Vuxg5kbdZlT2vJeoXHQjq Nrj6CBv3tRTd19r+zhCebKWU0dbQ7Yq1Oma2gEkbBFbck/Im4qSOeZU1e4HlL0z2u9mX AbEw== 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=O++cjIP/Yb6M/Fz+8+FUJaxmjT0kgwNBCs+xJSK/y7Y=; b=s8aSlBtya8Wb6BXklcfemab6UI8GX4p9MAHYABxAqSWTuDKbEIHqBX6wGqVJtgB48R nit9eNebPsm/T5jfNnYBlpoE3+b6Jbnx5Jr4HbmmH53e48rNPmwdWy4Gr1MUe4m/7r9T v7Hl1bbWAx2lJXww83jbTXk7Gl6As6x63e3mQYs3Iks2CGGBJbz/wMdTbND/HyIQ+RYc NKnpJ7D7n6L7qc1FtP6bhqwqMfWDboies39DC5P/Sd5MrROrbKQjslvq48C4vUXo6fsY sI5U5FONCd8qhG5r6KMUNSwuEFPTNdb3VYroSzConLa5kAHhtKxbFXA19WFTs6KJ3RAL 8Ftw== X-Gm-Message-State: ANoB5pmLg9/gSZhMeLkw88XqWcYzPhZpx8ZcYml4ut9U/syIcmZfEyil qk26BJlg9akgXV9K4EYBpDU= X-Google-Smtp-Source: AA0mqf6A6T6X6DnKGW6GnNQu7V/FPFvPmksvA7D/2MXzI98aTJvNjj9Do67dX+h5URv1JQylddRp5w== X-Received: by 2002:a17:90a:6308:b0:218:ce1c:4c76 with SMTP id e8-20020a17090a630800b00218ce1c4c76mr35659195pjj.97.1669697544146; Mon, 28 Nov 2022 20:52:24 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id n5-20020a170903110500b00176b63535adsm9651303plh.260.2022.11.28.20.52.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Nov 2022 20:52:23 -0800 (PST) Message-ID: Date: Mon, 28 Nov 2022 21:52:22 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH] RISC-V: Support the ins "rol" with immediate operand Content-Language: en-US To: Feng Wang , gcc-patches Cc: "kito.cheng" , research_trasio References: <20221128021428.13824-1-wangfeng@eswincomputing.com> <3419fa12-6de8-ab2f-ef36-fc849f67cabb@gmail.com> <2022112909535334321719@eswincomputing.com> From: Jeff Law In-Reply-To: <2022112909535334321719@eswincomputing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,BODY_8BITS,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 11/28/22 18:53, Feng Wang wrote: > on 2022-11-28 23:39  Jeff Law wrote: >> >> >> On 11/27/22 19:14, Feng Wang wrote: >>> From: wangfeng >>> >>> There is no Immediate operand of ins "rol" accroding to the B-ext, >>> so the immediate operand should be loaded into register at first. >>> But we can convert it to the ins "rori" or "roriw", and then one >>> immediate load ins can be reduced. >>> >>> Please refer to the following use cases: >>> unsigned long foo2(unsigned long rs1) >>> { >>>       return (rs1 << 10) | (rs1 >> 54); >>> } >>> >>> The complier result is: >>> li a1,10 >>> rol a0,a0,a1 >>> >>> This patch will generate one ins >>> rori a0,a0,54 >>> >>> gcc/ChangeLog: >>> >>>           * config/riscv/bitmanip.md: Add immediate_operand support in rotl RTL pattern >>> >>> gcc/testsuite/ChangeLog: >>> >>>           * gcc.target/riscv/zbb-rol-ror-04.c: New test. >>>           * gcc.target/riscv/zbb-rol-ror-05.c: New test. >> >> So this arrived after stage1 close and I'm not aware of an existing BZ >> around this issue, so I'd tend to think this should wait for stage1 to >> re-open in the spring. >> >> >> From a technical standpoint, would it be better to hand this in a more >> generic way?   ie, when converting from gimple into RTL, if we want to >> generate a rotate left by immediate and don't have a suitable insn, then >> change it to a rotate right by an adjusted immediate.    This could >> probably be done in optabs.cc::expand_binop. >> >> >> We might need similar code in combine.cc or simplify-rtx.cc since some >> rotate cases (or exposure of the constant) may not show up until later >> in the RTL pipeline. >> >> >> Anyway, doing this in a more generic way seems like it's worth >> investigating. >> >> >> jeff >> > Hi jeff, > > Thanks for your reply. In the currently it will judge the rotate shift number when converting from > gimple into RTL, if the shift number bigger than mode_size/2, then reverse the rotate direction. > I think the purpose of this process is to handle rotate shift quickly. I will think about your advice > and try to modify it in the expand pass. Yea, in the past there were targets where the cost of a shift or rotate was proportional to the number of bits shifted. So for a rotate in particular it was advantageous to reverse the rotation if the count was more than mode_size/2. I suspect such processors are a lot less common now than in the past. But we can probably utilize some of that code to suit our needs. Jeff