LATX, fix: Synchronize SSE FCSR state in softfpu modes

[yzewei]

While running the official test suite for a Python numerical computing library in the LAT environment, I discovered that when SoftFPU is enabled, native LoongArch FCSR exception flags generated by SSE/AVX instructions are not always reflected in the guest's MXCSR state. This can lead to inconsistencies or errors regarding exception flags or rounding modes across floating-point operations, architectural state observations, state restoration instructions, and signal frames.

Under the strict SoftFPU execution mode, x87 exceptions are maintained by SoftFloat in env->fpus, while SSE/AVX operations continue to use the native FCSR:

• The native SSE rounding mode is prepared only once per translation block (TB), and the cache is invalidated whenever MXCSR might change;
• Pending native FCSR exception flags are merged into env->mxcsr prior to executing STMXCSR, FXSAVE, XSAVE, and signal frame state observations;
• Stale native flags are cleared after executing LDMXCSR and floating-point state restoration paths;
• The host floating-point environment is saved and restored around the execution of x87 helpers that call native libm functions;
• The hard-float path remains unchanged.

This implementation targets the following configurations:

• LATX_SOFTFPU=1;
• LATX_SOFTFPU=2 with LATX_SOFTFPU_FAST=0.

When native x87 fast paths are enabled, x87 and SSE/AVX operations once again share the native FCSR and require full cross-domain synchronization; the current fix is ​​incompatible with this state.

New tests cover exception isolation, rounding modes, CVT/CVTT behavior, x87 stack pop semantics, FXSAVE/XSAVE restoration paths, and signal/ucontext state handling. With appropriate build environment support, AVX- and XSAVE-related test cases are automatically enabled.

[LaurenIsACoder]

感谢修复！

我建议再评估一下是否有必要让这套完整的 x87/SSE FCSR owner/dirty 状态机默认作用于所有 hard-float 应用，fcsr 指令开销大，会影响性能。

这个问题在 LATX_SOFTFPU=1 下实际上会简单很多：x87 运算主要通过 QEMU SoftFloat helper 执行，x87 exception 已经直接维护在 env->fpus 中，不再需要借 native FCSR 暂存；此时真正还需要处理的主要是 SSE/AVX native FCSR Flags 如何及时同步到 env->mxcsr。

因此建议先验证下面的矩阵：

• LATX_SOFTFPU=0
• LATX_SOFTFPU=1
• LATX_SOFTFPU=2 LATX_SOFTFPU_FAST=0
• LATX_SOFTFPU=2 + 当前使用的 FAST 配置

把现有 131 个 regression case 在这些模式下分别跑一遍。

如果 SOFTFPU=1 下 cross-domain case 已经自然通过，只剩 SSE native flags -> MXCSR 的同步问题，我更倾向于在 softfpu 模式下实现一个轻量方案：

• x87 exception 继续由 SoftFloat / env->fpus 维护；
• native FCSR 只作为 SSE/AVX 的 pending exception state；
• 在 STMXCSR / FXSAVE / XSAVE / signal/ucontext 等 architectural-state read 前把 SSE native flags merge 到 env->mxcsr；
• 不再维护 X87_DIRTY/SSE_DIRTY 双 domain 状态机。

这样可以避免为了少数要求严格 FP exception semantics 的应用，让所有 hard-float 浮点程序在每个 FP TB 上承担额外的 owner check / FCSR restore / state store 成本。

对于 SOFTFPU=2，需要特别注意 LATX_SOFTFPU_FAST：部分 fast x87 path 仍然使用 native LoongArch FP 指令，因此可能重新产生 native FCSR exception。可以先考虑在严格模式下关闭这些 fast bits，或者单独让这些 fast path 把 exception 提交回 env->fpus。

如果最终证明 softfpu 模式能够以明显更低成本满足 NumPy/SciPy 等应用的需求，我建议优先把它作为 per-application correctness mode，而不是直接让当前完整状态机默认影响所有应用。

[yzewei]

感谢修复！

我建议再评估一下是否有必要让这套完整的 x87/SSE FCSR owner/dirty 状态机默认作用于所有 hard-float 应用，fcsr 指令开销大，会影响性能。

这个问题在 LATX_SOFTFPU=1 下实际上会简单很多：x87 运算主要通过 QEMU SoftFloat helper 执行，x87 exception 已经直接维护在 env->fpus 中，不再需要借 native FCSR 暂存；此时真正还需要处理的主要是 SSE/AVX native FCSR Flags 如何及时同步到 env->mxcsr。

因此建议先验证下面的矩阵：

• LATX_SOFTFPU=0
• LATX_SOFTFPU=1
• LATX_SOFTFPU=2 LATX_SOFTFPU_FAST=0
• LATX_SOFTFPU=2 + 当前使用的 FAST 配置

把现有 131 个 regression case 在这些模式下分别跑一遍。

如果 SOFTFPU=1 下 cross-domain case 已经自然通过，只剩 SSE native flags -> MXCSR 的同步问题，我更倾向于在 softfpu 模式下实现一个轻量方案：

• x87 exception 继续由 SoftFloat / env->fpus 维护；
• native FCSR 只作为 SSE/AVX 的 pending exception state；
• 在 STMXCSR / FXSAVE / XSAVE / signal/ucontext 等 architectural-state read 前把 SSE native flags merge 到 env->mxcsr；
• 不再维护 X87_DIRTY/SSE_DIRTY 双 domain 状态机。

这样可以避免为了少数要求严格 FP exception semantics 的应用，让所有 hard-float 浮点程序在每个 FP TB 上承担额外的 owner check / FCSR restore / state store 成本。

对于 SOFTFPU=2，需要特别注意 LATX_SOFTFPU_FAST：部分 fast x87 path 仍然使用 native LoongArch FP 指令，因此可能重新产生 native FCSR exception。可以先考虑在严格模式下关闭这些 fast bits，或者单独让这些 fast path 把 exception 提交回 env->fpus。

如果最终证明 softfpu 模式能够以明显更低成本满足 NumPy/SciPy 等应用的需求，我建议优先把它作为 per-application correctness mode，而不是直接让当前完整状态机默认影响所有应用。

好的　我来测试一下，之前提出这个方案考虑的主要是如何在不开启SOFTFPU的情况下解决此类问题，如果SOFTFPU=1的效果比较好　可以基于SOFTFPU=1的情况去尝试轻量的完成问题的解决