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 9A23E44CA8 for ; Sat, 14 Jan 2023 04:09:03 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 279C168B6A9; Sat, 14 Jan 2023 06:09:01 +0200 (EET) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6844268AE2B for ; Sat, 14 Jan 2023 06:08:55 +0200 (EET) Received: by mail-lf1-f49.google.com with SMTP id b3so35752674lfv.2 for ; Fri, 13 Jan 2023 20:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=KDTsT0Slys8kkMHKhkEGDEr3cpdg5rF2Ll0wYI2+Dro=; b=o1MWIuwTyNKKR747snspBjCi+jm93PeCc/Dk/w38FJGw0Q0iMDjnBp39nPc6ZGCdOX sTYRVfPm+pZBAOdUBfb7o2pAKULDFSiqOI5NfGYdPiozOzZIKogTebYx1kuu0ayFpw0z m+WFMqlZDFEDWOmwsy915OGSvU8IcJ3CkHwiYBkA/AHrko+EeawrEtEmQJkH7/DuOer5 PcQLlSHrD6xIruapItb7onn8J8VxuyMCwTtTtHNmd6KSoZONgCvHgzpQk49e2XmMBpo3 ZYlDYUwHiFNRB7UuaaiouDDCPvj3nQ3LCdlK3R1EvBtEYPl4HgyXJGSUnw01k8hh8qXC zjmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KDTsT0Slys8kkMHKhkEGDEr3cpdg5rF2Ll0wYI2+Dro=; b=ZqJJUcyP4xJ20MaCv7Gmg/KlEZha0iUW4PCMOkYKZgdH7QvH2W6IR7/mF56py3g8x/ LpjTgyomZ+eEnBcyFpLMo/WXvpKqdCN7MHq09dSKgT+afw5wxAKvfqgoZ+WNwcKlYoo1 QoPPdX+wof6wHMAPZzFE26WZQblUtY33ND+N1NWnMOkQp2IVeEhxHP2eKFGE/kry7Z2y A0+3H0W8OOyKat/Ej7D6h1Yj3VzrG1p2Id8kYp/et7bb4gKPQNoI0D5fuXsdE96xYBg/ 4JbEfe9hVjLEZGF5QzJ0IQp43plOOB9QLZCzLjIl40oZH8qhsogvoSDJsPocqAbcsFrb OnXQ== X-Gm-Message-State: AFqh2koAUcY9MWNYIRQAD+kuem0IQMZLuIi2cTxy/5CpJ2jgWXVBNkAK aItgC2ZnixLFWAnrWngCiEbuGcqFKFbVV7RdM9klT7ksTg5zBw== X-Google-Smtp-Source: AMrXdXvTwIxbREQWyKADLKqVAIteulIVGdTXXrTogdbXVzIxSalVm2t38BAB+uQJBcWGNELacw+5f7Qm6paGJPggdSo= X-Received: by 2002:a05:6512:2216:b0:4b5:6c09:40a9 with SMTP id h22-20020a056512221600b004b56c0940a9mr4398138lfu.652.1673669333740; Fri, 13 Jan 2023 20:08:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rui Ueyama Date: Sat, 14 Jan 2023 12:08:42 +0800 Message-ID: To: ffmpeg-devel@ffmpeg.org 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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".