On 9 April 2016 at 23:45, Richard Henderson wrote:
> On 04/07/2016 02:58 AM, vija...@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
On 04/07/2016 02:58 AM, vija...@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
On 7 April 2016 at 10:58, wrote:
> From: Vijay
>
> Use Neon instructions to perform zero checking of
> buffer. This is helps in reducing downtime during
> live migration.
>
> Signed-off-by: Vijaya Kumar K
> Signed-off-by: Suresh
> ---
> util/cutils.c | 74
>
On 7 April 2016 at 11:30, Paolo Bonzini wrote:
>
>> +#elif defined __aarch64__
>> +#include "arm_neon.h"
>> +
>> +#define NEON_VECTYPE uint64x2_t
>> +#define NEON_LOAD_N_ORR(v1, v2)(vld1q_u64(&v1) | vld1q_u64(&v2))
>
> Why is the load and orr necessary? Is ((v1) | (v2)) enough?
> +#elif defined __aarch64__
> +#include "arm_neon.h"
> +
> +#define NEON_VECTYPE uint64x2_t
> +#define NEON_LOAD_N_ORR(v1, v2)(vld1q_u64(&v1) | vld1q_u64(&v2))
Why is the load and orr necessary? Is ((v1) | (v2)) enough?
> +#define NEON_ORR(v1, v2) ((v1) | (v2))
> +#
From: Vijay
Use Neon instructions to perform zero checking of
buffer. This is helps in reducing downtime during
live migration.
Signed-off-by: Vijaya Kumar K
Signed-off-by: Suresh
---
util/cutils.c | 74 +
1 file changed, 74 insertions
