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 1B82B3858413 for ; Fri, 7 Jan 2022 11:36:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B82B3858413 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 [10.20.4.52] (unknown [10.20.4.52]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9Dx_8vOJdhhLHcAAA--.2232S2; Fri, 07 Jan 2022 19:36:46 +0800 (CST) Subject: Re: [PATCH v4 04/12] LoongArch Port: Machine Decsription files. To: Xi Ruoyao , gcc-patches@gcc.gnu.org Cc: xuchenghua@loongson.cn, yangyujie@loongson.cn References: <20211224092817.728490-1-chenglulu@loongson.cn> <20211224092817.728490-5-chenglulu@loongson.cn> <4a67e7a1197b78d91c868aa75bebdf9a221ff10e.camel@mengyan1223.wang> From: =?UTF-8?B?56iL55KQ55KQ?= Message-ID: Date: Fri, 7 Jan 2022 19:36:46 +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: <4a67e7a1197b78d91c868aa75bebdf9a221ff10e.camel@mengyan1223.wang> Content-Language: en-US X-CM-TRANSID: AQAAf9Dx_8vOJdhhLHcAAA--.2232S2 X-Coremail-Antispam: 1UD129KBjvJXoW7AFWUCF4UuFWruFW5KFyrtFb_yoW8WF18pr W5AwsrtFZ8X3ZY9a17CrWUC3y29w1Sk3s8AF9Yg34vyry3Jr9IqryYkFnFqayDX34Fvay2 yr4j9343Z3y7J3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv214x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gc CE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2 z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4x0x7Aq67 IIx4CEVc8vx2IErcIFxwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG 8wCY02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r12 6r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa 7VUb_gA7UUUUU== X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, BODY_8BITS, HTML_MESSAGE, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2022 11:36:51 -0000 在 2022/1/7 上午1:54, Xi Ruoyao 写道: > On Fri, 2021-12-24 at 17:28 +0800, chenglulu wrote: >> +(define_insn "*zero_extendsidi2_internal" >> +  [(set (match_operand:DI 0 "register_operand" "=r,r,r") >> +       (subreg:DI (match_operand:SI 1 "nonimmediate_operand" "r,ZC,W") 0))] >> +  "TARGET_64BIT" >> +  "@ >> +   bstrpick.d\t%0,%1,31,0 >> +   ldptr.w\t%0,%1\n\tlu32i.d\t%0,0 >> +   ld.wu\t%0,%1" >> +  [(set_attr "move_type" "arith,load,load") >> +   (set_attr "mode" "DI") >> +   (set_attr "insn_count" "1,2,1")]) > This pattern is generating wrong code, causing > > FAIL: gcc.dg/compat/scalar-by-value-3 c_compat_x_tst.o-c_compat_y_tst.o execute > > This failure is a real bug, the reduced testcase is attached. In the > assembly: > > # ... > bstrins.d $r5,$r13,31,0 > addi.d $r12,$r22,-228 > bstrpick.d $r12,$r12,31,0 > bstrins.d $r5,$r12,63,32 > addi.w $r4,$r0,14 # 0xe > bl testvaci > > This obviously does not make any sense: it calculates the *address* of > g[0]'s imaginary part, truncates it to 32-bit, then pass it as the > *value* of the imaginary part to testvaci(). > > The problem is: before the reload pass, the compiler consider g[0] a > (virtual) register. It only becomes MEM after the reload pass. Adding > reload_completed as the condition of this insn seems able to fix the > issue. However I'm not sure if other insns need the change too. > >> +;; See the comment before the *and3 pattern why this is generated by >> +;; combine. > A minor issue: the comment before 'and3' does not exist. Thanks, we are working on this. In addition, we will check other instruction templates.