[LoongArch64] Handle LASX/LSX/FP context depending on ISA availability.

[LuckyXu-HF]

• Fix SDK running on 2K series SoC (related issue: LoongArch: LSX/LASX usage in CoreCLR #113354)
• Add HWCAP get in minipal_getcpufeatures().
• Do some clean up.

[LuckyXu-HF]

Please NOTE:

• Higher versions of clang for LA64 enabled LSX by default (while LASX is not enabled by default for now).
• Therefore, when building relevant elf and .a files in the SDK to run on 2K embedded platforms which not support LSX/LASX, the clang compilation flags -mno-lsx -mno-lasx must also be added to disable LSX/LASX support.

[LuckyXu-HF]

Hi @driver1998 , does this solve your problem?
cc @shushanhf

[driver1998]

cc @xen0n for review.
I have a similar patch locally driver1998/dotnet-nolsx@e608ccb and that works. This should just work I guess.

You may also need to test the 2K1000/2000/3000 series, those have LSX but no LASX.

(I didn't post my patch upstream because I am still waiting for my 2K3000 board to arrive lol)

[driver1998]

Although IIRC HWCAP should be preferred over CPUCFG, since there might be situations where the CPU supports LSX/LASX but the kernel disabled them.

see https://chromium-review.googlesource.com/c/libyuv/libyuv/+/6772567 for example.

[LuckyXu-HF]

cc @xen0n for review. I have a similar patch locally driver1998/dotnet-nolsx@e608ccb and that works. This should just work I guess.

You may also need to test the 2K1000/2000/3000 series, those have LSX but no LASX.

(I didn't post my patch upstream because I am still waiting for my 2K3000 board to arrive lol)

Yes, this patch can handle no LSX/LASX, only LSX , LSX && LASX cases on the coreclr side.

On the clang side, AFAIK lsx start enabled by default on clang19, so if we are using clang version>=19, we will need to add clang compilation option -mno-lsx for the platform which do not support LSX/LASX.

[LuckyXu-HF]

Although IIRC HWCAP should be preferred over CPUCFG, since there might be situations where the CPU supports LSX/LASX but the kernel disabled them.

see https://chromium-review.googlesource.com/c/libyuv/libyuv/+/6772567 for example.

Thanks, then we should consider similar judgment approach.
Does .NET have demand in such environments?

[driver1998]

Does .NET have demand in such environments?

Not sure, but AFAIK a VM running non-LASX kernel on something like a 3A6000 is used for simulating a 2K3000 in distro testing.

[am11]

Although IIRC HWCAP should be preferred over CPUCFG, since there might be situations where the CPU supports LSX/LASX but the kernel disabled them.

see https://chromium-review.googlesource.com/c/libyuv/libyuv/+/6772567 for example.

Good point. We can use similar approach taken here for riscv64 #113676 (see src/native/minipal/cpufeatures.c changes). You can add both old and new instructions in separate asm macros and at the call-site, use cpufeatures detection.

[LuckyXu-HF]

Although IIRC HWCAP should be preferred over CPUCFG, since there might be situations where the CPU supports LSX/LASX but the kernel disabled them.
see https://chromium-review.googlesource.com/c/libyuv/libyuv/+/6772567 for example.

Good point. We can use similar approach taken here for riscv64 #113676 (see src/native/minipal/cpufeatures.c changes). You can add both old and new instructions in separate asm macros and at the call-site, use cpufeatures detection.

Thanks very much. This approach is good to detect cpu features to add atomic/hwintrinsic/simd ISAs instead of inline assembly. I will add this in cpufeatures.c.

[jkotas]

The current version of the change looks good to me. Is it ok to merge it?

Thanks very much. This approach is good to detect cpu features to add atomic/hwintrinsic/simd ISAs instead of inline assembly. I will add this in cpufeatures.c.

This can be done in a follow up.

[xen0n]

Please properly separate logical changes, and say what you did, e.g. "Handle LASX/LSX/FP context depending on ISA availability" in the commit title. "Fix crash on 2K series SoC" should appear in the commit body because it's providing helpful additional context.

[xen0n]

I believe by not skipping over the following blocks, work is duplicated and important information (upper halves of XRs) is lost, because as it currently stands, the context layout doesn't guarantee a 256-bit XR is stored separately irrespective of LASX/LSX availability.

Example:

• If LASX is present:
  • CONTEXT_FPU_OFFSET + [0, 15]: xr0 lower half
  • CONTEXT_FPU_OFFSET + [16, 31]: xr0 upper half
• If only LSX is present:
  • CONTEXT_FPU_OFFSET + [0, 15]: vr0
  • CONTEXT_FPU_OFFSET + [16, 31]: vr1

On LoongArch cores with LASX (LSX is implied by LASX so it's always present in this case), xr0's upper half is NOT xr1, so with this context layout, information is lost by re-loading in the LSX way. Same for vr0's upper half vs f0.

[LuckyXu-HF]

Yes thanks, I also noticed this yesterday, will update.

[LuckyXu-HF]

If we had to run on the assumed environment which CPU supports LSX/LASX but the kernel disabled them (#118007 (comment)). Then we should call minipal_getcpufeatures to check instead of the cpucfg instruction, this should affect the performance. getauxval() does not involve syscall.

diff

diff --git a/src/coreclr/pal/src/arch/loongarch64/context2.S b/src/coreclr/pal/src/arch/loongarch64/context2.S
index 4e747c767d1..64403508453 100644
--- a/src/coreclr/pal/src/arch/loongarch64/context2.S
+++ b/src/coreclr/pal/src/arch/loongarch64/context2.S
@@ -37,13 +37,16 @@ LOCAL_LABEL(Restore_CONTEXT_FLOATING_POINT):
     andi $t1, $r21, (1 << CONTEXT_FLOATING_POINT_BIT)
     beqz $t1, LOCAL_LABEL(No_Restore_CONTEXT_FLOATING_POINT)
 
-    ori $r21, $zero, 2
-    cpucfg $r21, $r21
-    // CPUCFG.2.LASX[bit7]
-    andi $t1, $r21, 0x80
+    PROLOG_SAVE_REG_PAIR_INDEXED  22, 1, 24
+    st.d  $a0, $sp, 16
+    bl  C_FUNC(minipal_getcpufeatures)
+    ori  $r21, $a0, 0
+    ld.d  $a0, $sp, 16
+    EPILOG_RESTORE_REG_PAIR_INDEXED  22, 1, 24
+
+    andi $t1, $r21, LoongArch64IntrinsicConstants_LASX
     bnez $t1, LOCAL_LABEL(Restore_CONTEXT_LASX)
-    // CPUCFG.2.LSX[bit6]
-    andi $t1, $r21, 0x40
+    andi $t1, $r21, LoongArch64IntrinsicConstants_LSX
     bnez $t1, LOCAL_LABEL(Restore_CONTEXT_LSX)
 
     // 64-bits FPU. Not Support LSX/LASX
@@ -300,13 +303,16 @@ LOCAL_LABEL(Done_CONTEXT_INTEGER):
     andi  $t3, $t1, (1 << CONTEXT_FLOATING_POINT_BIT)
     beqz  $t3, LOCAL_LABEL(Done_CONTEXT_FLOATING_POINT)
 
-    ori $t1, $zero, 2
-    cpucfg $t1, $t1
-    // CPUCFG.2.LASX[bit7]
-    andi $t3, $t1, 0x80
+    PROLOG_SAVE_REG_PAIR_INDEXED  22, 1, 24
+    st.d  $a0, $sp, 16
+    bl  C_FUNC(minipal_getcpufeatures)
+    ori  $t1, $a0, 0
+    ld.d  $a0, $sp, 16
+    EPILOG_RESTORE_REG_PAIR_INDEXED  22, 1, 24
+
+    andi $t3, $t1, LoongArch64IntrinsicConstants_LASX
     bnez $t3, LOCAL_LABEL(Store_CONTEXT_LASX)
-    // CPUCFG.2.LSX[bit6]
-    andi $t3, $t1, 0x40
+    andi $t3, $t1, LoongArch64IntrinsicConstants_LSX
     bnez $t3, LOCAL_LABEL(Store_CONTEXT_LSX)
 
     // 64-bits FPU. Not Support LSX/LASX

[driver1998]

Maybe the value can be cached somewhere? I don't expect it will be changed at runtime.
Or maybe the performance penalty is not actually that high.

Also this can be delayed for later as well, no need to block this PR.

[LuckyXu-HF]

Or maybe the performance penalty is not actually that high.

I just debugged the getauxval() and it does not involve syscall, so I think call minipal_getcpufeatures here is feasible.

Also this can be delayed for later as well, no need to block this PR.

Agree. I will also try to find an environment where hardware supports LSX/LASX but the kernel disabled them.

[risc-vv]

@dotnet/samsung Could you please take a look? These changes may be related to riscv64.

[am11]

@LuckyXu-HF, I agree with @jkotas that we can keep cpufeatures changes out until the time they are actually used in C/C++ code. I see that you have CPU feature detection duplicated in asm and new code in cpufeatures.c is never exercised (i.e. minipal_getcpufeatures() not called and LoongArch64IntrinsicConstants_LSX and _LASX are unused). If you are not planing to use them, lets revert src/native/minipal for now.