ARM NEON support

[Licenser]

No description provided.

[vielmetti]

@Licenser -

When you have something that builds, please let me and @WorksOnArm know - would love to provide test cycles and diverse hardware to check out performance on.

[Licenser]

Thank you so much :D that's awesome!

[Licenser]

Nooo! it seems like we're going to be blocked on missing intrinsics :(

https://doc.rust-lang.org/core/arch/aarch64/index.html / rust-lang/stdarch#148

[vielmetti]

@Licenser Do you have an inventory yet of intrinsics that you need / intrinsics that are missing? Reading the linked issue, sounds like there's slow progress.

[Licenser]

Ah yes I made a list and then posted it to the wrong ticket ... silly me ...

Those are the intrinsics I found in @lemire's arm64 implementation

• vaddq_s8
• vandq_u8
• vceqq_s8
• vceqq_u8
• vcgtq_s8
• vcleq_u8
• vdupq_n_s8
• vdupq_n_u8
• vextq_s8
• vget_lane_u64 (broken implementation have not figured it out so far but v.X works)
• vgetq_lane_u16 (broken implementation have not figured it out so far but v.X works)
• vgetq_lane_u32 (broken implementation have not figured it out so far but v.X works)
• vgetq_lane_u64 (broken implementation have not figured it out so far but v.X works)
• vld1q_s8
• vld1q_u8
• vmovq_n_u8
• vmull_p64
• vorrq_s8
• vorrq_u8
• vpaddq_u8
• vqmovn_u64
• vqsubq_u8
• vqtbl1q_s8
• vqtbl1q_u8
• vreinterpret_u64_u32
• vreinterpretq_s8_u8
• vreinterpretq_u16_u8
• vreinterpretq_u32_u8
• vreinterpretq_u64_u8
• vreinterpretq_u8_s8
• vshrq_n_u8
• vst1q_u8

(there is a full list of missing instructions on the rust ticket - those are the required ones for porting simdjson.rs)

[sunnygleason]

@Licenser alas! Would you be open to the possibility of a PR that uses assembly macros in the meantime? Maybe it won't be that far off from the intrinsic version...

[Licenser]

Absolutely, I also gave you contributor permission so no or required;) I might take a look on the weekend to see what is required to get the intrinsics at least into nighly

[sunnygleason]

@Licenser that's awesome - I'll take a pass at defining some intrinsics in 'src/neon/intrinsics.rs', and we can compare notes as you work with nightly!

[Licenser]

I started working on a pull request: rust-lang/stdarch#792

[lemire]

We just published simdjson 0.2.0 with NEON support...

[Licenser]

Huzza!

[Licenser]

OMG OMG OMG! this is great! :D

[sunnygleason]

@Licenser are you thinking we might be able to merge this today and then have a subsequent PR to delete the intrinsics once everything's available in nightly? Thank you again for all your help. PS the new UTF8 tests look great!

[Licenser]

I'd rather not, I could see that in resulting in some headache downstream if the intrinsics make it in and that'd be very, very, very hacky for a crate.

That said brave people ca already use it as a git dependency by pointing to the git branch.

[sunnygleason]

Ah, that makes sense. What is taking you so long?!! ;)

[Licenser]

Literally this:

• vget_lane_*: https://godbolt.org/z/gkIiLz
• vld1q_*: https://rust.godbolt.org/z/cUzoLB
• vextq_s8: https://rust.godbolt.org/z/5-s-f2

[sunnygleason]

Maybe I found something? Let me know what you think... https://godbolt.org/z/36hnUE

#[cfg(target_arch = "aarch64")]
#[cfg_attr(target_arch = "arm", target_feature(enable = "v7"))]
#[rustc_args_required_const(1)]
pub unsafe fn vget_lane_u8(a: uint8x8_t, n: u32) -> u8 {
    if n < 0 || n > 7 {
        unreachable_unchecked();
    };
    match n {
        0 => a.0,
        1 => a.1,
        2 => a.2,
        3 => a.3,
        4 => a.4,
        5 => a.5,
        6 => a.6,
        7 => a.7,
        _ => unreachable_unchecked()
    }
}

(Also clang: https://clang.godbolt.org/z/TpqJIp)

[sunnygleason]

@Licenser I think your vld1q is all set, since the intrinsic turns into ldr anyway?

• clang: https://clang.godbolt.org/z/1bvH2x
• rust: https://rust.godbolt.org/z/C7aiaG

[Licenser]

Oh that's a very good catch! then the ld1 commands are indeed done :D

for vget_lane_u8 yes that one is possiuble, the other ones are that cause me headache :(

[Licenser]

This leaves only those two functions:

// uint64_t vget_lane_u64 (uint64x1_t v, const int lane)
arm_vget_lane!(vget_lane_u64, uint64x1_t, u64, 0);

#[simd_test(enable = "neon")]
unsafe fn test_vget_lane_u64() {
    let v = i64x1::new(1);
    let lane = 0;
    let r = vget_lane_u64(transmute(v), lane);
    assert_eq!(r, 1);
}


// uint32_t vgetq_lane_u32 (uint32x4_t v, const int lane)
arm_vget_lane!(vgetq_lane_u32, uint32x4_t, u32, 3);

#[simd_test(enable = "neon")]
unsafe fn test_vgetq_lane_u32() {
    let v = i32x4::new(1, 2, 3, 4);
    let lane = 1;
    let r = vgetq_lane_u32(transmute(v), lane);
    assert_eq!(r, 2);
}

[Licenser]

vget_lane_u64 is done, I took your approach Sunny and verified that gcc also turns it into a fmov instead of a vmov commented and published it.

[sunnygleason]

@Licenser that's awesome work... very nice!

I think some of the "ldr" confusion is because the operands are
in memory versus a register, and optimization gets in the way
for constants. I made this example with system time to prevent
optimization and show the "st1" usage: https://godbolt.org/z/SK6A7j

Does this look good? Let me know what you think!

All the best, -Sunny