x86指令cmpeqpd偶发返回错误比较结果，是否存在影响其行为的隐藏微架构状态

• 程序运行中偶发浮点比较指令执行结果异常，触发指令为cmpeqpd xmm3,xmm0
• 指令执行前实测寄存器状态：
  • xmm0 存储值为 {0x2cd000000000, 0x2cd000000000}，两个元素均为非规格化双精度浮点数（IEEE 754指数字段全为0，数值远小于最小正规格化数）
  • xmm3 存储值为 {0x0, 0x2011d0800000000}，第一个元素为+0.0，第二个元素为常规规格化双精度浮点数
• 按常规浮点比较逻辑，预期两个lane的数值均不相等，执行后xmm3应返回全0
• 实际异常返回值为 {0xffffffffffffffff, 0x0}，即低64位lane判定两数相等、高64位lane判定不相等，和预期不符
• 复现特征：问题偶发触发，通过rr工具录制完整执行流程可稳定复现，将程序极度精简后无法复现，已提前确认对应YMM寄存器的高128位处于清零状态
• 核心疑问：是否存在会改变cmpeqpd/cmppd行为的隐藏微架构状态？

• 该异常并非无规律的微架构硬件bug，是x86浮点控制寄存器MXCSR中的**DAZ（Denormals Are Zero，非规格化数按零处理）**控制位被意外开启导致的、完全符合架构规范的行为
  • DAZ位的定义是：当该位置1时，所有参与运算的输入操作数若为非规格化浮点数，硬件会在运算单元内部直接将其转换为对应符号的0值参与计算，整个转换过程不会修改寄存器中存储的原始位模式，仅在运算链路内生效。这也是为什么通过调试器读到的寄存器值完全没变，比较结果却和值的原始表示不匹配
  • 对应当前场景：当DAZ位开启时，xmm0中存储的两个非规格化浮点数会被硬件直接转为+0.0。此时低64位lane下，xmm3的原始存储值就是+0.0，和被转换为0的xmm0值完全相等，因此硬件返回全1的相等标记；高64位lane下xmm3存储的是规格化浮点数，不会被DAZ规则转换，和被转成0的xmm0值不相等，因此返回全0的不等标记，和观测到的异常结果完全吻合
• 为什么问题是偶发、精简程序无法复现：
  • DAZ/FTZ（Flush To Zero，计算产生的非规格化结果按零处理）控制位通常是高性能计算、快速数学类代码主动设置的——这类代码为了绕开非规格化数运算的高延迟开销，进入执行路径时会主动修改MXCSR寄存器开启相关选项。如果代码执行中遇到提前返回、长跳转、异常分支等场景，没有在退出前将MXCSR恢复到默认状态，就会留下“DAZ已开启”的残留状态，影响后续所有浮点指令的执行
  • 程序极度精简时，会直接移除这些会临时修改MXCSR状态的代码路径，自然无法触发这类残留状态的问题
• 所谓“隐藏微架构状态”本质是开发者普遍忽略的MXCSR寄存器控制位：这是x86浮点架构明确定义的标准控制寄存器，并非完全不透明的微架构内部状态，只是绝大多数应用层开发不会主动校验MXCSR的实际取值，才会把这个符合规范的行为误判为硬件异常。之前确认YMM高128位清零的排查是正确的，但这和当前问题没有关联。

• 在异常复现的位置，于目标指令执行前读取MXCSR寄存器的实际值，检查第6位（DAZ位）、第15位（FTZ位）是否被置1
• 全局检索代码中所有通过stmxcsr/ldmxcsr指令修改MXCSR寄存器的逻辑，排查是否存在修改后未恢复的执行路径

内容的提问来源于stack exchange，提问作者Bikineev