From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id B89F53858D38 for ; Fri, 4 Nov 2022 03:07:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B89F53858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [10.20.4.52]) by gateway (Coremail) with SMTP id _____8AxHLb0gWRjSmcEAA--.3232S3; Fri, 04 Nov 2022 11:07:33 +0800 (CST) Received: from [10.20.4.52] (unknown [10.20.4.52]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Dx_eHzgWRj9iwNAA--.36939S2; Fri, 04 Nov 2022 11:07:31 +0800 (CST) Subject: Re: [PATCH v3] LoongArch: Optimize immediate load. To: Xi Ruoyao , gcc-patches@gcc.gnu.org Cc: i@xen0n.name, xuchenghua@loongson.cn References: <20221101120444.412376-1-chenglulu@loongson.cn> <5b19fb73fc15ae68951118a96393ed2222b41190.camel@xry111.site> <2250cca5-a1c9-aecc-9b01-1b6e52ec5e06@loongson.cn> <2d547e6296b28f9e8efcc3352fb363ca8967bff6.camel@xry111.site> From: Lulu Cheng Message-ID: <447853bb-0f96-f71a-399f-112ac1f9b457@loongson.cn> Date: Fri, 4 Nov 2022 11:07:30 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <2d547e6296b28f9e8efcc3352fb363ca8967bff6.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8Dx_eHzgWRj9iwNAA--.36939S2 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBjvJXoWxArW8Aw4DKr1kurWrGF1DGFg_yoW5AFyUpr yvy3WUtFZ8Jrn3Gr1Dtw1UXr98tryxG3WUZFn8JFyxGr47Jr1Fqr4UXryq9F1DJw4rGr1j qF15J347ZF15Aw7anT9S1TB71UUUUUDqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bakYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2 IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487Mx AIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMxCIbckI1I0E14v26r126r1D MI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67 AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0 cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z2 80aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIF yTuYvjxUwmhFDUUUU X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,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: 在 2022/11/4 上午10:56, Xi Ruoyao 写道: > On Fri, 2022-11-04 at 10:33 +0800, Lulu Cheng wrote: >> 在 2022/11/4 上午10:22, Xi Ruoyao 写道: >>> On Tue, 2022-11-01 at 20:04 +0800, Lulu Cheng wrote: >>>> gcc/ChangeLog: >>>> >>>>          * config/loongarch/constraints.md (x): New constraint. >>>>          * config/loongarch/loongarch.cc (struct loongarch_address_info): >>>>          Adds a method to load the immediate 32 to 64 bit field. >>>>          (struct loongarch_integer_op): Define a new member curr_value, >>>>          that records the value of the number stored in the destination >>>>          register immediately after the current instruction has run. >>>>          (LARCH_MAX_INTEGER_OPS): Define this macro as 3. >>>>          (LU32I_B): Move to the loongarch.h. >>>>          (LU52I_B): Likewise. >>>>          (loongarch_build_integer): Adds a method to load the immediate >>>>          32 to 63 bits. >>>>          (loongarch_move_integer): Likewise. >>> We need to mention "call set_unique_reg_note" here because it seems the >>> key to resolve the issue. >> During debugging, I found the problem because the source register and >> destination register of the lu32i.d instruction are the same. As a >> result, during loop2_invariant pass, the destination register of >> lu32i.d is used twice, so the instructions after this instruction will >> not be brought out of the loop. Therefore, I combined lu32i.d and >> lu52i.d into one template, which avoids the situation that the same >> register is used twice. It is not split into two instructions until >> loop2_invariant has been optimized. So I don't think >> "set_unique_reg_note" plays a decisive role in this optimization. > It's better to mention this logic in the commit message then, to prevent > others from misunderstandings like mine. > > Again the code change LGTM and I've tested it with --with-build- > config=bootstrap-ubsan. > Ok, I'll describe this logic. Thanks! >>> Otherwise LGTM. >>> >>>>          (loongarch_print_operand_reloc): Modifying comment information. >>>>          * config/loongarch/loongarch.h (LU32I_B): Move from loongarch.cc. >>>>          (LU52I_B): Likewise. >>>>          (HWIT_UC_0xFFFFFFFF): New macro. >>>>          (HI32_OPERAND): New macro. >>>>          * config/loongarch/loongarch.md (load_hi32): New template. >>>>          * config/loongarch/predicates.md (const_hi32_operand): Determines >>>>          whether the value is an immediate number that has a value of only >>>>          the higher 32 bits. >>>>          (hi32_mask_operand): Immediately counts the mask of 32 to 61 bits.