ARM64EC vector algorithms

[AlexGuteniev]

• Why they need to exist always when x64 algorithms exist?
• How to make them executed?
• Can we have coverage for that?

[jovibor]

There shouldn't be separate vector algorithms for the ARM64EC arch, at all.

In terms of intrinsics there are only two types of them - x64/x86 and ARM64.
And the ARM64EC arch should utilize ARM64 vector algorithms for the best performance.

The ARM64EC is basically ARM64 code with the x64 compatible ABI, for seamless interability.

Here is a good explanation:

You also have the option to further optimize the processor-specific code in your project by using ARM64 intrinsic functions in your ARM64EC project. The _M_ARM64EC preprocessor macro allows you to differentiate ARM64EC from x64 and take ARM-specific code paths rather than x64. For example, if you have code that already handles choosing the best intrinsic functions for x64 and ARM64, you can key off _M_ARM64EC or _M_ARM64 to use the ARM intrinsic functions, as below:

[AlexGuteniev]

In terms of intrinsics there are only two types of them - x64/x86 and ARM64.
And the ARM64EC arch should utilize ARM64 vector algorithms for the best performance.

The question is mostly about the cases where we don't have ARM64 intrinsics path yet, but vectorized functions still exist and probably can be executed.

[StephanTLavavej]

Why they need to exist always when x64 algorithms exist?

I think the ARM64EC vector_algorithms.cpp is used when x64 user .obj files are linked into an ARM64EC binary. That's why the ARM64EC surface must always match the x64 surface.

How to make them executed?
Can we have coverage for that?

We now have ARM64EC runtime coverage.

I believe that this is now superseded by #813. I expect we'll get ARM64 vectorized implementations of all algorithms that are currently done for x64/x86, and we are now simultaneously activating them for ARM64EC.

[AlexGuteniev]

How to make them executed?
Can we have coverage for that?

We now have ARM64EC runtime coverage.

I believe that this is now superseded by #813. I expect we'll get ARM64 vectorized implementations of all algorithms that are currently done for x64/x86, and we are now simultaneously activating them for ARM64EC.

I think discrepancies can always exist. Like, if there was no SVE and were restricted by Neon, we couldn't have replace, see #6090:

we cannot implement in-place replace using Neon

Similarly it was mentioned on Discord that remove/unique may be problematic due to movemask lack. It is proposed that compact from SVE2 should be used.

Bitset from string also needs movemask. And vector<bool> from vector<uintN_t>, when we get to it. It is possible that search_n is blocked by the same, And here compact won't help, we don't use movemask to achieve some other goal, movemask itself is the goal.

So I think it may be preferrable to test the ARM64EC mirrors of x64 vectorization.

[AlexGuteniev]

But yes, the need for having ARM64EC coverage is way lower now that we can have at least the usual searches vectorized normally.

[AlexGuteniev]

The actual coverage was introduced here:

• Vector algorithms: runtime coverage for ARM64EC non-vectorized fallbacks again #6107
• Vector algorithms: trim runtime coverage for ARM64EC non-vectorized fallbacks #6142