These could have beenVector128<byte>.AllBitsSet

It's not clear why these all need to be declared up front. It's effectively defining unnecessary locals and work for the JIT to do.

This could have beenvar decLutOne = (Vector128<byte>.AllBitsSet, Vector128<byte>.AllBitsSet, Vector128.Create(0xFFFFFFFF, 0xFFFFFFFF, 0x3EFFFFFF, 0x3FFFFFFF).AsByte(), Vector128.Create(0x37363534, 0x3B3A3938, 0xFFFF3D3C, 0xFFFFFFFF).AsByte()) instead, as an example.

Similar here, it's not clear why these were defined up front like this. They could have been declared in the loop at the declaration site (since they aren't used outside the loop) making the overall code much more readable, without needing 15 up front declarations

Vector128.Create<byte>(0x3F) is preferred overAdvSimd.DuplicateToVector128.

The former allows more general optimizations to kick in as it does not prescribe a particular instruction be emitted.

I know this is pre-existing to the PR, but this is not a great method name. It should probably be something likeAssertReadIsValid or similar.

It would be nice ifLoadVector128x4AndUnzip was something we could pattern match and implicitly light up.

Did you mean a wrapper method, sayLoadVectorAndUnzip(), that would do the right thing based on the return type?

No, rather as per my comment above (#100589 (comment)) we prefer to write xplat code so logic can be shared across CPU architectures where possible.

To facilitate this, we ideally have the JIT recognize simple patterns and optimize them.LoadVector128x4, for example, could be done automatically if the JIT were to recognize 4x sequentialVector128.Load.

LoadVector128x4AndUnzip could theoretically have the same done if we were to recognize 4x sequenceVector128.Load and a general pattern forunzip. Today that would be recognizingShuffle in particular, but longer term it might be a good reason for there to be an xplatVector128.Unzip (since that just corresponds toUnzip on Arm64 andUnpack onx64).

The driving question tends to be, "does this logic actually have to be platform/ISA specific, or is there a simple pattern we could enable the JIT to recognize instead?". In the case simple pattern recognition is possible, then it's generally ideal to enable it so that existing user code lights up and gets faster on Arm64 without the need for users to go and manually do the work. It also lets the same code automatically light-up for things likeAdvSimd vsSVE, rather than being strictly tied down toAdvSimd.

Right, thanks for this clarification. I'll keep this mind for the common patterns in the future.

This general algorithm probably could do with a comment walking through what's happening so the "magic" is better understood, much as exists forVector128Decode

Agreed, it's difficult to follow. Although, it's a bit tricky to describe the entire workings with lookup tables and interleaving. I'll try to make it less opaque.

These could have been the xplatVector128.GreaterThan(str1, offset)

I didn't understand the xplat bit. Could you elaborate on this, please?

We have APIs defined onVector128 that expose functionality common across multiple ISAs (AdvSimd, SVE, etc) and common across multiple architectures (Arm64, x64, WASM, etc).

Using these APIs tends to be preferred over using the platform specific APIs, particularly when there is a clear 1-to-1 mapping. Thusx + y is preferred overAdvSimd.Add andVector128.GreaterThan is preffered overAdvSimd.CompareGreaterThan.

Using the xplat (cross platform) APIs gives the JIT more flexibility in the code it generates and allows more portability, while also often improving readability.

Makes sense, I'll update these calls 👍

These could have been of the formres1 = (str1 << 2) | (str2 << 4);