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: Mon, 9 Jan 2023 23:48:11 +0200 (EET)
Message-ID: <11fe364a-3822-471-7f82-1aefe9c0ce49@martin.st> (raw)
In-Reply-To: <bb82744-22ed-8dc4-ed77-ed681230d9e9@martin.st>

On Mon, 9 Jan 2023, Martin Storsjö wrote:

> Hi Rui,
>
> Long time no see!
>
> 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?
>
> What am I missing here?

In particular, it seems like the commits 
b22db4f465c9adb2cf1489e04f7b65ef6bb55b8b and 
e84212b78e00df17799e01be1e153a073eb8f689 were introduced to fix exactly 
this issue - by converting references from using the external global 
symbols into local labels instead.

// 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".