From: Richard Henderson <rth@twiddle.net>
To: vijayak@caviumnetworks.com, qemu-arm@nongnu.org,
peter.maydell@linaro.org, pbonzini@redhat.com
Cc: vijay.kilari@gmail.com, Prasun.Kapoor@caviumnetworks.com,
knv.suresh2009@gmail.com, qemu-devel@nongnu.org,
Suresh <ksuresh@caviumnetworks.com>, Vijay <vijayak@cavium.com>
Subject: Re: [Qemu-devel] [RFC PATCH v2 1/3] target-arm: Use Neon for zero checking
Date: Sat, 9 Apr 2016 15:45:43 -0700 [thread overview]
Message-ID: <57098617.1020308@twiddle.net> (raw)
In-Reply-To: <1460023087-31509-2-git-send-email-vijayak@caviumnetworks.com>
On 04/07/2016 02:58 AM, vijayak@caviumnetworks.com wrote:
> +#elif defined __aarch64__
> +#include "arm_neon.h"
A better test is __NEON__, which asserts that neon is available at compile time
(which will be true basically always for aarch64), and then you don't need a
runime test for neon.
You also get support for armv7 with neon.
> +#define NEON_VECTYPE uint64x2_t
> +#define NEON_LOAD_N_ORR(v1, v2) (vld1q_u64(&v1) | vld1q_u64(&v2))
> +#define NEON_ORR(v1, v2) ((v1) | (v2))
> +#define NEON_NOT_EQ_ZERO(v1) \
> + ((vgetq_lane_u64(v1, 0) != 0) || (vgetq_lane_u64(v1, 1) != 0))
FWIW, I think that vmaxvq_u32 would be a better reduction for aarch64.
Extracting the individual lanes isn't as efficient as one would like.
For armv7, folding via vget_lane_u64(vget_high_u64(v1) | vget_low_u64(v1), 0)
is probably best.
r~
next prev parent reply other threads:[~2016-04-09 22:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 9:58 [Qemu-devel] [RFC PATCH v2 0/3] ARM64: Live migration optimization vijayak
2016-04-07 9:58 ` [Qemu-devel] [RFC PATCH v2 1/3] target-arm: Use Neon for zero checking vijayak
2016-04-07 10:30 ` Paolo Bonzini
2016-04-07 10:44 ` Peter Maydell
2016-04-07 10:44 ` Peter Maydell
2016-04-09 22:45 ` Richard Henderson [this message]
2016-04-11 10:40 ` Peter Maydell
2016-04-07 9:58 ` [Qemu-devel] [RFC PATCH v2 2/3] utils: Add cpuinfo helper to fetch /proc/cpuinfo vijayak
2016-04-07 10:11 ` Peter Maydell
2016-04-07 10:56 ` Vijay Kilari
2016-04-07 11:45 ` Peter Maydell
2016-04-08 6:21 ` Vijay Kilari
2016-04-08 9:43 ` Peter Maydell
2016-04-11 6:52 ` Vijay Kilari
2016-04-11 9:37 ` Suzuki K Poulose
2016-04-13 9:54 ` Vijay Kilari
2016-04-13 9:59 ` Suzuki K Poulose
2016-05-09 3:30 ` Vijay Kilari
2016-05-09 10:59 ` Suzuki K Poulose
2016-05-09 11:21 ` Peter Maydell
2016-05-09 13:44 ` Catalin Marinas
2016-05-10 10:24 ` Will Deacon
2016-05-10 13:06 ` Catalin Marinas
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=57098617.1020308@twiddle.net \
--to=rth@twiddle.net \
--cc=Prasun.Kapoor@caviumnetworks.com \
--cc=knv.suresh2009@gmail.com \
--cc=ksuresh@caviumnetworks.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vijay.kilari@gmail.com \
--cc=vijayak@cavium.com \
--cc=vijayak@caviumnetworks.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).