> On 27 Jul 2023, at 15:55, Rémi Denis-Courmont <r...@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-requ...@ffmpeg.org with subject "unsubscribe".
