From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 604FE45122 for ; Mon, 9 Jan 2023 16:01:24 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 579D768BC6C; Mon, 9 Jan 2023 18:01:21 +0200 (EET) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E07F168BAA0 for ; Mon, 9 Jan 2023 18:01:14 +0200 (EET) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 309G1DsO014211-309G1DsP014211 for ; Mon, 9 Jan 2023 18:01:13 +0200 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id 9768FA1428 for ; Mon, 9 Jan 2023 18:01:13 +0200 (EET) Date: Mon, 9 Jan 2023 18:01:11 +0200 (EET) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: Message-ID: References: MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] [PATCH] arm32/neon: Avoid using bge/beq for function calls X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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".