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 7BB183858407 for ; Fri, 5 Aug 2022 02:38:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7BB183858407 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 AQAAf9DxAM+fguxijCMHAA--.28144S2; Fri, 05 Aug 2022 10:38:23 +0800 (CST) Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mltQQVRDSCB2NV0gTG9vbmdBcmNoOiBhZGQgbW92?= =?UTF-8?Q?able_attribute?= To: Xi Ruoyao , "gcc-patches@gcc.gnu.org" Cc: Chenghua Xu , Youling Tang , Huacai Chen , Jinyang He , Wang Xuerui References: <9b6b0e68cfb7e87ae961ef8a7bb7987f534da19c.camel@xry111.site> <6cafbcdf79f77b73b9329f3e3a2f24ec85eda94d.camel@xry111.site> <-2muj1c-68saz6jhkcyw3jo1xp-1mgcvnkbqi2wjp6tue-qsso54-emxgu3-k85590-kpgox7-w67u6h3cai1l-5bi887dsgzsu-g4d7i7-wl316qxrucx4kv4on7-mnna36-iremg8-nwc5ot-9041t2-hu8nsl.1659495047941@email.android.com> <90d2f698eaa2ef88712e9aef453b1deff197b533.camel@xry111.site> <44a2cb6f-b8b2-babb-bfcc-3dd17d8fce42@loongson.cn> <60bac545a09ee202d41421a596ac64a4cb83d89c.camel@xry111.site> From: Lulu Cheng Message-ID: Date: Fri, 5 Aug 2022 10:38:23 +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: <60bac545a09ee202d41421a596ac64a4cb83d89c.camel@xry111.site> Content-Language: en-US X-CM-TRANSID: AQAAf9DxAM+fguxijCMHAA--.28144S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tr4kGF4rZFWfJr43ury8Krg_yoW8AFWxpF WFk3yavrZrXrySkF48Jw1Ika1fKa1rW343Xry0k3WxZ3yDXw1vvFs2yrn0qayxJr18Z343 ZFyq9F1SqrW8Z3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvS14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxV W0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487McIj6xIIjxv20xvE14v26r1j6r18McIj 6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lF7I21c 0EjII2zVCS5cI20VAGYxC7Mx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vI Y487MxkIecxEwVCm-wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s 026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_ JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20x vEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280 aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43 ZEXa7VU1g4S7UUUUU== X-CM-SenderInfo: xfkh0wpoxo3qxorr0wxvrqhubq/ X-Spam-Status: No, score=-5.1 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 05 Aug 2022 02:38:29 -0000 在 2022/8/5 上午9:28, Xi Ruoyao 写道: > On Fri, 2022-08-05 at 09:05 +0800, Lulu Cheng wrote: >> I'm working on the implementation of specifing attributes of variables for other architectures. >> If the address is obtained through the GOT table and 4 instructions, there is not much difference in performance. > In this case I still prefer a GOT table entry because for 4-instruction > absolute addressing sequence we'll need to implement 4 new relocation > types in the kernel module loader. If it is accessed through the GOT table, dynamic relocation is required when the module is loaded. And accessing the got table may have a cache miss. >> Is it more reasonable for us to refer to the implementation of the model attribute under the IA64 architecture? > Maybe we can use "model(got)", "model(abs)", "model(pcrel)" etc. We have a set of instruction implementations that can get a relative pc 64-bit offset:   "pcalau12i %1,%%pc_hi20(%3);"   "addi.d %2,$r0,%%pc_lo12(%3);"   "lu32i.d %2,%%pc64_lo20(%3);"   "lu52i.d %2,%2,%%pc64_hi12(%3);"   "add.d %1,%1,%2;", This set of instructions can be selected according to the size of the offset:   "pcalau12i %1,%%pc_hi20(%3);"   "addi.d %2,$r0,%%pc_lo12(%3);"   "lu32i.d %2,%%pc64_lo20(%3);"   "add.d %1,%1,%2;", for offset within signed 52 bits. or   "pcalau12i %1,%%pc_hi20(%3);"   "addi.d %2,$r0,%%pc_lo12(%3);"   "lu32i.d %2,%%pc64_lo20(%3);"   "lu52i.d %2,%2,%%pc64_hi12(%3);"   "add.d %1,%1,%2;" for offset within signed 64 bits. So my idea is "model(normal)","model (large)" etc. >> I will compare the performance of the two soon. Do you know the approximate release date of GCC 12.2? >> I also want to fix this before 12.2 is released. > GCC 12.2 rc1 will be frozen on Aug 12th. >