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 715113858D37 for ; Fri, 5 Aug 2022 07:58:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 715113858D37 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+Ozexi2KAHAA--.29445S2; Fri, 05 Aug 2022 15:58:07 +0800 (CST) Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mltQQVRDSCB2NV0gTG9vbmdBcmNoOiBhZGQgbW92?= =?UTF-8?Q?able_attribute?= To: WANG Xuerui , Xi Ruoyao , "gcc-patches@gcc.gnu.org" Cc: Youling Tang , Chenghua Xu , Huacai Chen , Jinyang He References: <-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> <3aebe438b53e84eab24824f6cc79ae655cfb0f72.camel@xry111.site> <4789106a3b8ca37bd0f810b818eb14cae5fc9cac.camel@xry111.site> <76ddfa4a-6c7c-8c67-c6cd-4d6ae0bc87a5@xen0n.name> From: Lulu Cheng Message-ID: <069670e7-faf3-ecd4-be4f-3b0f8debb508@loongson.cn> Date: Fri, 5 Aug 2022 15:58:06 +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: <76ddfa4a-6c7c-8c67-c6cd-4d6ae0bc87a5@xen0n.name> Content-Language: en-US X-CM-TRANSID: AQAAf9DxAM+Ozexi2KAHAA--.29445S2 X-Coremail-Antispam: 1UD129KBjvJXoW7uFyDZr1rur15WrW5ZFWfGrg_yoW8tF4xpF W3GF1YyF4kC393W34vgw1xJFWfuan7Jay5Jry7Ja4vv34agw12yrsFk34a9F97Zrn7A34Y va1avw1DAFy5AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUva14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r4j6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j 6r4UJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gc CE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2 z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4x0x7Aq67 IIx4CEVc8vx2IErcIFxwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG 8wCY02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r12 6r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv 67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyT uYvjfUwYFCUUUUU 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, T_SCC_BODY_TEXT_LINE 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 07:58:13 -0000 在 2022/8/5 下午3:41, WANG Xuerui 写道: > On 2022/8/5 15:19, Lulu Cheng wrote: >> >> >> 在 2022/8/5 下午2:03, Xi Ruoyao 写道: >>> On Fri, 2022-08-05 at 12:01 +0800, Lulu Cheng wrote: >>>> 在 2022/8/5 上午11:45, Xi Ruoyao 写道: >>>> >>>>> On Fri, 2022-08-05 at 11:34 +0800, Xi Ruoyao via Gcc-patches wrote: >>>>> >>>>>> Or maybe we should just use a PC-relative addressing with 4 instructions >>>>>> instead of GOT for -fno-PIC? >>>>> Not possible, Glibc does not support R_LARCH_PCALA* relocations in >>>>> ld.so. So we still need a -mno-got (or something) option to disable GOT >>>>> for special cases like the kernel. >>>>> >>>>>> Both way consumes 16 bytes (4 instructions >>>>>> for PC-relative, 2 instructions and a 64-bit GOT entry for GOT) and PC- >>>>>> relative may be more cache friendly.   But such a major change cannot be >>>>>> backported for 12.2 IMO. >>>> I'm very sorry, my understanding of the precpu variable is wrong, >>>> I just read the code of the kernel you submitted, this precpu variable >>>> not only has a large offset but also has an uncertain address when compiling, >>>> so no matter whether it is addressed with pcrel Still got addressing needs >>>> dynamic relocation when loading. It seems that accessing through the got table >>>> is a better choice. >>>> >>>> The name movable is also very vivid to describe this function in the kernel, >>>> indicating that the address of the variable can be changed at will. >>>> >>>> But this name is more difficult to understand in gcc, I have no opinion on other, >>>> can this name be changed? >>> Yes, we don't need to be compatible with old vendor compiler IMO. >>> >>> >>> "force_got_access" as Xuerui suggested? >> Compared with these names, I think addr_global is better. > > Actually if "model(...)" can be implemented I'd prefer a descriptive > word/phrase inside model(). Because it may well be the case that more > peculiar ways of accessing some special data will have to be supported > in the future, and all of them are kind of "data models" so we'd be > able to nicely group them with model(...). > > Otherwise I actually don't have a particularly strong opinion, aside > from "movable" which IMO should definitely not be taken. > > I think the model of precpu is not very easy to describe. model(got)?model(global)? I also want to use attribute model and -mcmodel together, but this is just an initial idea, what do you think?