Optimize Vector128.Create() that takes 15 arguments

[kunalspathak]

As suggested by @TamarChristinaArm in #35590 (comment) , revisit to see if Vector128.Create() that takes 15 arguments can be optimized by loading later half of them directly from stack into upper-half of Vector128.

category:cq
theme:hardware-intrinsics
skill-level:intermediate
cost:small
impact:small

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

[tannergooding]

I'm not sure how useful this optimization will be in practice. I would expect in the vast majority case that all inputs are either constant or mostly constant and cases where the user is providing 16 or close to 16 non-constant inputs is rare.

In the case of all inputs being constant, we should be creating an 8-byte or 16-byte constant and loading it directly.
In the case of most inputs being constant, we should create a partial constant and then insert the remaining values to the appropriate indices (we could likely look to LLVM to determine where a "good cutoff" is).

I have a prototype locally that does the above for x86, its just not something I've had time to finish yet.

[TamarChristinaArm]

I'm not sure how useful this optimization will be in practice. I would expect in the vast majority case that all inputs are either constant or mostly constant and cases where the user is providing 16 or close to 16 non-constant inputs is rare.

Maybe..., I don't imagine you would need this call much either, but my concern is mostly that the codegen from this is currently very inefficient. There's no reason for it to generate a value on the genreg side, do a zero extend and then move it to the SIMD side with an insert (negating the need for the zero extend). It should have just loaded it on the SIMD side.

So the question is, is this a problem with this call or something more fundamental.

For the rest I agree that constant values should have some kind of store merging support.

[AndyAyersMS]

Going to mark this as future; @kunalspathak if you think it needs to be in 5.0 we can discuss.

[kunalspathak]

@AndyAyersMS - I agree.