[x264-devel] Fwd: rbit and HAVE_ARMV6T2
Martin Storsjö
martin at martin.st
Mon Apr 17 21:50:38 CEST 2017
Hi Andrei,
On Mon, 17 Apr 2017, Andrei Gherzan wrote:
> I encountered an issue while compiling x264 for armv6 based
> RaspberryPi boards . The thumb instruction rbit is not available for
> all armv6 but only from armv6t2 which is not the case for the
> RapsberryPi boards based on armv6. These boards come with armv6z.
>
> x264 configure script checks, using HAVE_ARMV6T2, if armv6t2 specific
> instructions are available but then, when compiling, quant-a.S is
> picked and compiled with rbit instruction unconditionally.
>
> One way to fix it would be to use --disable-asm but this disables all
> the optimisations even though this is the only instruction failing (if
> I remove this specific instruction the build completes successfully).
>
> The better way to do it would be, in my opinion , to emulate this
> instruction when unavailable. What do you guys think?
Indeed, this instruction is only available on armv6t2.
However, there's not much point in emulating the instruction here,
since it's within a NEON function, and NEON implies armv6t2. So the
codepath won't ever actually be executed on a pre-armv6t2 device.
When building x264 for arm, it pretty much assumes being able to assemble
NEON instructions (and blindly sets ".fpu neon" making the NEON
instructions available), but only sets .arch armv7-a if the toolchain's
baseline includes armv7.
I think the best course of action would be to make it set .arch armv7-a
unconditionally as well, since all the armv7-neon code is built
unconditionally anyway. The individual codepaths won't be executed anyway,
unless the runtime check indicates that neon is available.
Does the attached patch fix the issue you're facing?
// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-arm-Always-unconditionally-declare-.arch-armv7-a.patch
Type: text/x-diff
Size: 1077 bytes
Desc:
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20170417/01b07b5a/attachment.patch>
More information about the x264-devel
mailing list