Open
Description
I am trying to port CoreCLR to the 2K0300 SoC, a LoongArch SoC with no LSX/LASX support.
From what I can see, SIMD JIT codegen is guarded behind FEATURE_SIMD and is not enabled by default, so that's fine.
But context switching code in PAL uses LASX xvld
/xvsd
instruction to load/save floating point/vector registers without any checks.
See:
This breaks on 2K0300, and I think also the 2K1000 / 2K2000 chips that do have LSX but no LASX.
I partially reverted the change (d74b524) and got a ImageSharp / dotnet-iot sample running on the 2K0300. Will still need to figure out a cleaner way to do it, like checking LSX/LASX support in runtime and use the correct instructions in each senario.
Activity
[-]LoongArch LSX/LASX usage in CoreCLR[/-][+]LoongArch: LSX/LASX usage in CoreCLR[/+]dotnet-policy-service commentedon Mar 11, 2025
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.
driver1998 commentedon Mar 11, 2025
cc @shushanhf @LuckyXu-HF
shushanhf commentedon Mar 11, 2025
Thanks, we will check it.
xen0n commentedon Mar 11, 2025
Yeah, CPU capabilities should be checked upfront by means of HWCAP.