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

["Martin Storsjö" <martin@martin.st>]

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?

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