From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] mplayer: fix compilation of NEON assembly in libavcodec
Date: Mon, 15 Oct 2012 22:49:13 +0200 [thread overview]
Message-ID: <507C76C9.4080202@mind.be> (raw)
In-Reply-To: <87d30qadw4.fsf@macbook.be.48ers.dk>
On 10/10/12 11:13, Peter Korsgaard wrote:
> Arnout> neon fpu (like vfp* fpu) can only be used with the softfp abi,
> Arnout> so both are needed. This is kind of standard ARM knowledge:-)
>
> It is? I've never done any real work on platforms with neon, so it's
> certainly a bit fussy to me, but I don't understand what the relation is
> with the calling convention.
>
> Aren't the new linaro toolchains hardfp and support neon?
So these are my conclusions.
- Neon with hard float abi is indeed possible - teaches me not to trust the
gcc manpages :-) BTW, the float abi is not just the function calling convention,
but also how float variables are laid out in memory - that's why it has an
impact on assembly code as well.
- That means, you need mfloat-abi=softfp on soft abi libc (e.g. sourcery) and
mfloat-abi=hard on hard abi libc (e.g. linaro). It will be tough for buildroot
to distinguish between them and select the right -mfloat-abi. On Linaro,
-mfloat-abi=hard is the default so it can be left out, but on Sourcery,
-mfloat-abi=softfp is required (default is soft).
- Internal toolchains are soft abi unless
BR2_EXTRA_GCC_CONFIG_OPTIONS="--with-float=hard" so they also need the
-mfloat-abi=softfp
- So we could just document in the external toolchains which options should be
given to enable neon.
- The vadd.i16 test in mplayer's configure script would detect that neon is not
available (because the -mfloat-abi and -mfpu options are not in CFLAGS) --
except that the test is disabled because we explicitly specify --enable-neon.
- ffmpeg itself always does the test, even if we give --enable-neon.
So I propose to document the NEON options in the external toolchains, and to
remove --enable-neon from mplayer. I'm not sure what to do with internal
and crosstool-ng toolchains.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
prev parent reply other threads:[~2012-10-15 20:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-05 23:03 [Buildroot] [PATCH] mplayer: fix compilation of NEON assembly in libavcodec Arnout Vandecappelle
2012-10-05 23:45 ` Sagaert Johan
2012-10-08 20:27 ` Peter Korsgaard
2012-10-09 21:29 ` Arnout Vandecappelle
2012-10-10 9:13 ` Peter Korsgaard
2012-10-15 6:53 ` Peter Korsgaard
2012-10-15 19:05 ` Arnout Vandecappelle
2012-10-15 20:49 ` Arnout Vandecappelle [this message]
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=507C76C9.4080202@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.