On Mon, 13 Jan 2014, Diego Biurrun wrote:
On Mon, Jan 13, 2014 at 03:31:18PM +0100, Janne Grunau wrote:
On 2014-01-12 16:36:37 +0100, Diego Biurrun wrote:
On Sat, Jan 11, 2014 at 06:03:23PM +0100, Janne Grunau wrote:
+NEON-ASM-OBJS-$(CONFIG_H264CHROMA) += aarch64/h264cmc_neon.o
+
+NEON-OBJS-$(HAVE_NEON_EXTERNAL) += $(NEON-ASM-OBJS)
$(NEON-ASM-OBJS-yes)
This indirection seems unnecessary; what are you trying to do here?
It's necessary since clang-3.3 can't assemble the neon objects but
HAVE_NEON doesn't get disabled.
So what stops you from fixing that and disabling HAVE_NEON for clang 3.3?
I think that might be more straightforward.
On ARM right now, HAVE_NEON is always enabled if we can assemble neon
given the right .arch/.fpu flags while HAVE_NEON_EXTERNAL is enabled if we
can do NEON without any extra .arch/.fpu directives. If tools that can't
assemble NEON on 32 bit would be common, we might need a test for ".arch
armv7-a .fpu neon <neon instruction>" and disable HAVE_NEON if that fails.
Since on aarch64, you should be able to assemble neon instructions without
any extra directives, I guess it would be just as consistent to disable
HAVE_NEON if we can't assemble neon instructions at all.
Adding something similar to this would probably be helpful:
map 'enabled_any ${v}_external ${v}_inline || disable $v' \
$ARCH_EXT_LIST_ARM
If we'd add runtime feature detection later as on arm, we would probably
want to add a separate test analogue to ".arch armv7-a .fpu neon <instr>".
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
