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

From: Rui Ueyama <rui314@gmail.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] arm32/neon: Avoid using bge/beq for function calls
Date: Sat, 14 Jan 2023 12:08:42 +0800
Message-ID: <CACKH++b3TB4nLVSFm5jPWa0SO79MXf-mc4m0cBK3ZfJ4vhuZrA@mail.gmail.com> (raw)
In-Reply-To: <CACKH++YDMtFrb7eMf__D=yXkVjHDZ_P6aC1qawCqUX6XMaJO6Q@mail.gmail.com>

Hey Martin,

It's nice to see you on this mailing list!

Sorry about sending this email as a reply to a wrong email, as I
didn't receive your mail and thus couldn't send this as a reply to
your mail.

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

Rui
_______________________________________________
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".