Re: 回复：[PATCH v5] LoongArch: add movable attribute

[WANG Xuerui <i@xen0n.name>]

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.