ARM64 intrinsic support for Vector64.Create() and Vector128.Create()

[kunalspathak]

Added hardware intrinsic for various overloads of Vector64.Create() and Vector128.Create():

• Multiple arguments - The APIs that takes multiple parameters to be set in respective lanes are implemented in C# using AdvSimd.Insert.
• Single arguments - The APIs that takes single argument and should be copied in all lanes are implemented in JIT by generating dup/mov/fmov instructions.

While I was there, I noticed an edge case where we hit assert if trying to emit an immediate int.MaxValue. Fixed it as well.

Contributes to #33308 and #33496.
Fixes: #35821

[kunalspathak]

@dotnet/jit-contrib , @tannergooding

[BruceForstall]

cc @TamarChristinaArm

[TamarChristinaArm]

not for this PR, but since we only have 8 argument registers the rest will be passed on the stack.
In which case would be easier to load the remaining 64 bits into a register directly from the stack into the top part of the 128-bit vector.

i.e. do something like this:

        and     w0, w0, 255
        fmov    s0, w0
        ins     v0.b[1], w1
        ins     v0.b[2], w2
        ins     v0.b[3], w3
        ins     v0.b[4], w4
        ins     v0.b[5], w5
        ins     v0.b[6], w6
        ins     v0.b[7], w7
        ld1     {v0.d}[1], [sp]

And you can do this is something like this for a lot of the cases with more than 8 arguments. Do you know what the code generates here at the moment?

[kunalspathak]

That's a good point which I didn't realize. I will explore your suggestion.

Generated code

        53001C00          uxtb    w0, w0
        4E011C10          ins     v16.b[0], w0
        53001C20          uxtb    w0, w1
        4E031C10          ins     v16.b[1], w0
        53001C40          uxtb    w0, w2
        4E051C10          ins     v16.b[2], w0
        53001C60          uxtb    w0, w3
        4E071C10          ins     v16.b[3], w0
        53001C80          uxtb    w0, w4
        4E091C10          ins     v16.b[4], w0
        53001CA0          uxtb    w0, w5
        4E0B1C10          ins     v16.b[5], w0
        53001CC0          uxtb    w0, w6
        4E0D1C10          ins     v16.b[6], w0
        53001CE0          uxtb    w0, w7
        4E0F1C10          ins     v16.b[7], w0
        B94023A0          ldr     w0, [fp,#32]  // [V08 arg8]
        53001C00          uxtb    w0, w0
        4E111C10          ins     v16.b[8], w0
        B9402BA0          ldr     w0, [fp,#40]  // [V09 arg9]
        53001C00          uxtb    w0, w0
        4E131C10          ins     v16.b[9], w0
        B94033A0          ldr     w0, [fp,#48]  // [V10 arg10]
        53001C00          uxtb    w0, w0
        4E151C10          ins     v16.b[10], w0
        B9403BA0          ldr     w0, [fp,#56]  // [V11 arg11]
        53001C00          uxtb    w0, w0
        4E171C10          ins     v16.b[11], w0
        B94043A0          ldr     w0, [fp,#64]  // [V12 arg12]
        53001C00          uxtb    w0, w0
        4E191C10          ins     v16.b[12], w0
        B9404BA0          ldr     w0, [fp,#72]  // [V13 arg13]
        53001C00          uxtb    w0, w0
        4E1B1C10          ins     v16.b[13], w0
        B94053A0          ldr     w0, [fp,#80]  // [V14 arg14]
        53001C00          uxtb    w0, w0
        4E1D1C10          ins     v16.b[14], w0
        B9405BA0          ldr     w0, [fp,#88]  // [V15 arg15]
        53001C00          uxtb    w0, w0
        4EB01E08          mov     v8.16b, v16.16b
        4E1F1C08          ins     v8.b[15], w0
        D28D0500          movz    x0, #0x6828
        F2A6EF60          movk    x0, #0x377b LSL #16
        F2CFFFA0          movk    x0, #0x7ffd LSL #32
        6E084509          mov     v9.d[0], v8.d[1]
        97FF53EA          bl      CORINFO_HELP_NEWSFAST
        6E180528          mov     v8.d[1], v9.d[0]
        3C808008          str     q8, [x0,#8]

And you can do this is something like this for a lot of the cases with more than 8 arguments.

Actually, this is the only API that has more than 8 arguments.

[echesakov]

I wonder how hard is goint to be to get rid of the uxtb-s

[kunalspathak]

yeah, I am not much familiar with this, but would love to get rid of them. Just to call out, they show up for byte, sbyte, short and ushort parameters.

[echesakov]

yeah, I am not much familiar with this, but would love to get rid of them. Just to call out, they show up for byte, sbyte, short and ushort parameters.

Correct, because these types are usually "normalized" (i.e. sign- or zero-extended) to a 32 bit value

[TamarChristinaArm]

Yeah, those aren't needed indeed, would be good to get rid of them if possible since they double the number of instructions.

Also

        B94053A0          ldr     w0, [fp,#80]  // [V14 arg14]
        53001C00          uxtb    w0, w0
        4E1D1C10          ins     v16.b[14], w0

Without the optimization I talked about above should ideally be

ld1 {v16.b[14]}, [x1]

where x1 gets incremented, or you could use a which prevents from having to move between register files. But also don't know how easy this is to do..

[kunalspathak]

I briefly discussed various options with @echesakovMSFT and concluded that it might not be straight forward. I would like to revisit it after we implement other APIs. Opened #35688 to track it.

[echesakov]

Looks Good to me with some questions/suggestions.

[echesakov]

@kunalspathak You might want to add comment here in the same fashion as it's done for Sse2 case

[kunalspathak]

Spoke offline and this is not needed.

[kunalspathak]

@tannergooding and @echesakovMSFT - Just FYI, while working on something else I found 2 issues for which we don't have test coverage today.

1. Vector64.Create((double)10) (any integer value casted to double)
2. Passing Vector64<double> or Vector64<long> as parameter to a function.

I will fix and add test coverage for it before merging.