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 13404385840F for ; Fri, 4 Nov 2022 02:33:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 13404385840F 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 _____8CxjdoJemRjG2MEAA--.14962S3; Fri, 04 Nov 2022 10:33:46 +0800 (CST) Received: from [10.20.4.52] (unknown [10.20.4.52]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxqFcDemRjNyYNAA--.19024S2; Fri, 04 Nov 2022 10:33:41 +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> From: Lulu Cheng Message-ID: <2250cca5-a1c9-aecc-9b01-1b6e52ec5e06@loongson.cn> Date: Fri, 4 Nov 2022 10:33:39 +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: <5b19fb73fc15ae68951118a96393ed2222b41190.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8CxqFcDemRjNyYNAA--.19024S2 X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Coremail-Antispam: 1Uk129KBjvJXoWxJr4kCFy3XFy7tw4DJFW3GFg_yoW5JF17pr 1vvr1DJFW5Jrn3Gr1DJ34UXr9xJryxG3W2vFn5JFy7Gr4UJryFqr4UWFyj9Fn8Jw48Gr1j qr15Jr13uF15Aw7anT9S1TB71UUUUUDqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bI8YFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2 IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487Mx AIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_ Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwI xGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcV C2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUwmhFDUUUU X-Spam-Status: No, score=-5.0 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: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. > > 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.