Based on #25215, the latest branch code is adapted

It's better to devide into multiple patches.

I think the usage of LoongArch64 and LoongArch is somewhat confusing. For now, we can standardize on LoongArch64, and later, if necessary, we can add support for LoongArch32.

Add Linux Qemu tests for LoongArch64.

I think the usage of LoongArch64 and LoongArch is somewhat confusing. For now, we can standardize on LoongArch64, and later, if necessary, we can add support for LoongArch32.

Has been uniformly modified to loongarch64

It's better to devide into multiple patches.

Done

Add Linux Qemu tests for LoongArch64.

Already added

We discussed this in a recent traige meeting from the perspective of long-term support for loongarch. We at one point decided to move our kernels to Highway which does not currently support loongarch. The general opinion was that we would like to merge this as-is, with the caveat that we may disable it if the split between the two kernel systems (universal intrinsics and highway) becomes too much of a maintenance burden. The contributors are welcome to join our slack channel to discuss the longer term maintenance going forward, or to join a optimization working group meeting.

Sorry to bother you. How much longer will it take to merge this PR, or is there any additional work we need to do?

Hi @XiWeiGu , Highway TL here. We are willing to merge a LoongSIMD patch and maintain it if it can be tested using a commonly available QEMU. Happy to discuss via issue on the Highway github.

Hi @XiWeiGu , Highway TL here. We are willing to merge a LoongSIMD patch and maintain it if it can be tested using a commonly available QEMU. Happy to discuss via issue on the Highway github.

Thank you for your response. Currently, the cross-toolchain and QEMU for LoongArch are fully available. Further discussions on LoongArch support will be carried out on the Highway GitHub issue.

If I am not wrong, you are not building the source file with LSX optimizations. Could you also run benchmark numbers?

Also, there is an already an older PR #27402 which is converting this very source file to Highway. And since Highway doesn't support LoongArch just yet, we might want to prioritize getting Loongarch supported on highway.

I can run benchmarks, it support LSX on my test environment.

If I am not wrong, you are not building the source file with LSX optimizations. Could you also run benchmark numbers?

Also, there is an already an older PR #27402 which is converting this very source file to Highway. And since Highway doesn't support LoongArch just yet, we might want to prioritize getting Loongarch supported on highway.

Considering that Highway supports general scalar instructions, I will submit a PR to Highway as soon as possible to add support for LoongArch, ensuring that PR (#27402) will not cause issues on the LoongArch platform once merged.

Considering that Highway supports general scalar instructions, I will submit a PR to Highway as soon as possible to add support for LoongArch, ensuring that PR (#27402) will not cause issues on the LoongArch platform once merged.

Sounds good. It is a little involved to add a target: about 10 places require updating. It is quite doable by searching for all occurrences of say AVX3_ZEN4 (except in x86_*) and adding something there. If you prefer, I can also help by making this change, without actually adding any intrinsics. If so, what should be the name of the targets(s)? HWY_LSX?

Considering that Highway supports general scalar instructions, I will submit a PR to Highway as soon as possible to add support for LoongArch, ensuring that PR (#27402) will not cause issues on the LoongArch platform once merged.

Sounds good. It is a little involved to add a target: about 10 places require updating. It is quite doable by searching for all occurrences of say AVX3_ZEN4 (except in x86_*) and adding something there. If you prefer, I can also help by making this change, without actually adding any intrinsics. If so, what should be the name of the targets(s)? HWY_LSX?

Thank you very much for your kind help; that would be best if possible. Yes, the target name will be HWY_LSX. Do you need any other information about LoongArch?

You should not be working in your main branch.

You should not be working in your main branch.

Thank you for your feedback. We will create a new branch to submit the code.

Thank you very much for your kind help; that would be best if possible. Yes, the target name will be HWY_LSX. Do you need any other information about LoongArch?

:) I intend to add the new HWY_LSX target on Friday.
There are some capability flags in set_macros-inl.h that I will guess, we can also change them later.
One thing that would be helpful to understand: what are the vector sizes? I saw mention of 128 and 256 bit. In what way does that depend on the CPU?

Thank you very much for your kind help; that would be best if possible. Yes, the target name will be HWY_LSX. Do you need any other information about LoongArch?

:) I intend to add the new HWY_LSX target on Friday. There are some capability flags in set_macros-inl.h that I will guess, we can also change them later. One thing that would be helpful to understand: what are the vector sizes? I saw mention of 128 and 256 bit. In what way does that depend on the CPU?

The vector size of the LSX instruction set is 128 bits, while the vector size of the LASX instruction set is 256 bits.
LoongArch provides the cpucfg instruction to check whether the CPU supports the LSX or LASX instruction sets. However, this may not always be reliable, as some systems might disable LSX and LASX instruction sets for various reasons. Therefore, even if the hardware supports them, we still need to disable the respective instruction sets at runtime. The getauxval interface can be used to determine whether the system supports LSX or LASX.

Got it. Highway supports this use case by compiling both LSX and LASX targets, and then dispatching to whichever is present. google/highway#2388 has the basics of this ready.

Closing, replaced by #27856

replaced by #27856, Thank you everyone.