On 2014-07-04 18:27:54 +0300, Martin Storsjö wrote: > See [1] for discussion on the issue with using 'setend' on modern > arm versions. > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/268504.html > --- > libavcodec/arm/h264dsp_init_arm.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/arm/h264dsp_init_arm.c > b/libavcodec/arm/h264dsp_init_arm.c > index 92658e7..dd21418 100644 > --- a/libavcodec/arm/h264dsp_init_arm.c > +++ b/libavcodec/arm/h264dsp_init_arm.c > @@ -104,8 +104,12 @@ av_cold void ff_h264dsp_init_arm(H264DSPContext *c, > const int bit_depth, > { > int cpu_flags = av_get_cpu_flags(); > > - if (have_armv6(cpu_flags)) > + if (have_armv6(cpu_flags) && !(have_vfpv3(cpu_flags) || > have_neon(cpu_flags))) { > + // This function uses the 'setend' instruction which is deprecated > + // on ARMv8. We don't have cpuflags for ARMv7/ARMv8, but such devices > + // should have VFPv3 and NEON set. > c->h264_find_start_code_candidate = > ff_h264_find_start_code_candidate_armv6; > + }
I don't think this is a good solution for the almost non-problem. 'setend' is deprecated but still available. It can be disabled through a system control register but I can't see a reason why anyone should disable it especially if 32-bit compatibility is important. Not that this single optimization is important - it actually annoys me since valgrind doesn't emulate setend - but disabling it even on armv7 seems a little extreme. If we care about armv7 instructions which are deprecated on armv8 the partial deprecation of 'it' is even more annoying. The non-deprecated 'it' on armv8 allows just a single conditional instruction. We use the deprecated form in 15 files (grep for ' it[te]+ '). Thumb2 is afaik default on android and ios. At least on ios both deprecated 32-bit instructions are not a problem and I wouldn't expect it to be a problem on android either for the foreseeable future (as long as both allow installation of 32-bit apps on armv8 devices). Janne _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
