From: "Reimar Döffinger" <Reimar.Doeffinger@gmx.de>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] Replace br return with ret
Date: Thu, 27 Jul 2023 19:22:11 +0200
Message-ID: <9FED04FD-FB51-4037-81F5-9FCB17FE2473@gmx.de> (raw)
In-Reply-To: <F3E3CFC9-4F01-45BD-9258-679D52F63D5F@remlab.net>
> On 27 Jul 2023, at 15:55, Rémi Denis-Courmont <remi@remlab.net> wrote:
>
> Hi,
>
> The use of RET vs BR also has microarchitectural side effects. AFAIU, RET should always be paired with an earlier BL/BLR to avoid interfering with branch prediction.
>
> So depending on the circumstances, either one of these should be addressed:
> * Clarify that this is actually a function return , and RET should be used anyway, regardless of BTI.
> * Keep BR and add BTI J landing pads where appropriate, if this wasn't really a function return.
Yes BL and RET is best to match up.
For this function:
% git grep func_tr_32x4
libavcodec/aarch64/hevcdsp_idct_neon.S:function func_tr_32x4_\name
libavcodec/aarch64/hevcdsp_idct_neon.S: bl func_tr_32x4_firstpass
libavcodec/aarch64/hevcdsp_idct_neon.S: bl func_tr_32x4_secondpass_\bitdepth
libavcodec/arm/hevcdsp_idct_neon.S:function func_tr_32x4_\name
libavcodec/arm/hevcdsp_idct_neon.S: bl func_tr_32x4_firstpass
libavcodec/arm/hevcdsp_idct_neon.S: bl func_tr_32x4_secondpass_\bitdepth
It is always used with "bl", thus ret is also more correct from
that aspect.
Was your comment only on checking that, or did you mean that this should
be mentioned in the commit message?
(if you are wondering why the code did not use ret before, I guess it's
because it was ported from the 32-bit arm assembler and it slipped by code review)
Best regards,
Reimar
_______________________________________________
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".
next prev parent reply other threads:[~2023-07-27 17:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-27 10:26 Casey Smalley
2023-07-27 13:55 ` Rémi Denis-Courmont
2023-07-27 17:22 ` Reimar Döffinger [this message]
2023-08-04 9:14 ` Casey Smalley
2023-08-04 10:48 ` Martin Storsjö
2023-08-08 12:22 Casey Smalley
2023-08-08 17:46 ` Martin Storsjö
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9FED04FD-FB51-4037-81F5-9FCB17FE2473@gmx.de \
--to=reimar.doeffinger@gmx.de \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git