Re: [FFmpeg-devel] [PATCH] arm32/neon: Avoid using bge/beq for function calls

From: "Martin Storsjö" <martin@martin.st>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] arm32/neon: Avoid using bge/beq for function calls
Date: Sun, 15 Jan 2023 00:30:37 +0200 (EET)
Message-ID: <f8abd1d1-54f7-f6a2-ec7-6daa967217f4@martin.st> (raw)
In-Reply-To: <CACKH++b3TB4nLVSFm5jPWa0SO79MXf-mc4m0cBK3ZfJ4vhuZrA@mail.gmail.com>

Hi Rui,

On Sat, 14 Jan 2023, Rui Ueyama wrote:

>> On Sat, 7 Jan 2023, Rui Ueyama wrote:
>>
>>> It looks like compiler-generated code always uses `b`, `bl` or `blx`
>>> instructions for function calls. These instructions have a 24-bit
>>> immediate and therefore can jump anywhere between PC +- 16 MiB.
>>>
>>> This hand-written assembly code instead uses `bge` and `beq` for
>>> interprocedural jumps. Since these instructions have only a 19-bit
>>> immediate (we have less bits for condition code), they can jump only
>>> within PC +- 512 KiB. This sometimes causes a "relocation R_ARM_THM_JUMP19
>>> out of range" error when linked with the mold linker. This error can
>>> easily be avoided by using `b` instead of `bge` or `beq`.
>>
>> Can you add a bit more explanation about what happens in mold in this case
>> and context about the setup - I don't quite understand how this can happen
>> (even if the code admittedly is a bit unusual)?
>>
>> Since .L_swri_oldapi_conv_flt_to_s16_neon and
>> .L_swri_oldapi_conv_fltp_to_s16_2ch_neon are local symbols, they don't get
>> emitted by the assembler, and the branch instructions are encoded with
>> fixed offsets and no relocations. And even if there would be a relocation,
>> the destination is within the same text section chunk in the object file,
>> so it shouldn't be possible for it to be out of range.
>>
>> The only possibility for this to be out of range, is if the destination is
>> treated as a global and routed via the PLC?
>
> There was confusion on our side. ffmpeg used to contain two
> audio_convert_neon.S as below
>
> libswresample/arm/audio_convert_neon.S
> libavresample/arm/audio_convert_neon.S
>
> and the latter had a problem that I explained in the previous mail.
> But that file has been removed, so there's no problem with the
> existing code. I'll retract the patch I sent before. Sorry for the
> confusion.

Ah, I see - that explains it!

Ok, good then, that there's no issue with that code pattern in assembly - 
otherwise there could be a whole lot of issues to run into...

// Martin

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".