Re: [PATCH] LoongArch: Add new relocation R_LARCH_CALL36

[chenglulu <chenglulu@loongson.cn>]

在 2023/11/8 下午7:04, Xi Ruoyao 写道:
> On Wed, 2023-11-08 at 01:34 +0800, WANG Xuerui wrote:
>> On 11/7/23 20:16, Xi Ruoyao wrote:
>>> I'd like to have some pseudo instructions:
>>>
>>> - call36 r0, t0, func -> pcaddu18i t0, func + jirl r0, t0, func
>>> - call36 t0, func -> pcaddu18i t0, func + jirl t0, t0, func
>>> - call36 func -> pcaddu18i ra, func + jirl ra, ra, func
>>>
>>> These will make the work of the compiler (or assembly programmer)
>>> easier.  Anyway with R_LARCH_CALL36 the pcaddu18i instruction and the
>>> jirl instruction must be adjacent, so there is no benefit for the
>>> compiler or programmer to use them separately to make a function call.
>>>
>>> And the last one can be annotated with R_LARCH_RELAX so we may relax it
>>> into a bl instruction if possible.
>> The suggestion sounds reasonable! Although IMO a name like "call.36"
>> might look better, the name "call36" also works for me.
>>
>> And regarding the proposed "call36 func" reusing the $ra for the
>> temporary -- IIUC this will break the subroutine return prediction. I
>> think we've been hit by similar regalloc in GCC and have since fixed
>> that: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11013.
> The URL is wrong, PR 11013 is 20-years old.
>
>> So maybe it's necessary to specify a different temp register after
>> all...
> I think for a normal call (call36 $ra, $ra, func or just call36 $ra) it
> should be OK, but for a sibcall (call36 $zero, $ra, func) it will
Under what circumstances do we generate such a function call?:-[
> confuse the return predictor and we better use another temp register.
>