mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-10-01 14:58:14 +00:00
Henrik RydgårdandClaude Opus 5
46632812cd
Two bugs stacked on each other, and between them every vector path in this backend was either dead or miscompiled. The register cache declared mapFPUSIMD unconditionally, but every compiler here picks its path from cpu_info.LOONGARCH_LSX at runtime. Without LSX the scalar fallbacks ran against a SIMD mapping and reached lanes with F(reg + n), which addresses nothing there - ApplyMapping only allocates per-lane registers when mapFPUSIMD is false. Vec4Unpack8To32 and Vec4DuplicateUpperBitsAndShift1 came out with only their first lane, Vec2Unpack16To32 put both halves in one register, and the pack ops read back whatever was next door. riscv64 sets the flag false and has never had the problem. Tie the two together and the fallbacks are correct as they stand. That path was reachable because of the second one: the USE_CPU_FEATURES block assigned over the hwcaps, and GetLoongArchInfo reads /proc/cpuinfo and nothing else. Under qemu-user that file belongs to the host, so it found no features and turned LSX off - leaving the LSX paths dead and the untested scalar ones running, which is not what any Loongson 3A5000 or later does. Let it only ever add to what the hwcaps found. cpu/vfpu/convert, gum and matrix pass now, both with LSX and with it masked off, putting loongarch64 at 338/342 - the same four as riscv64. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>