为什么这段代码在优化开启或关闭时表现不同？答案

【问题标题】：Why does this code behave differently with optomisations on or off?为什么这段代码在优化开启或关闭时表现不同？
【发布时间】：2012-09-11 00:11:21
【问题描述】：

我有一个简单的测试运行程序来解决我的 OpenPGP 模块 https://github.com/singpolyma/OpenPGP-Haskell/blob/master/Data/OpenPGP.hs 中的错误：

module Main where

import Data.OpenPGP
import Data.Binary (encode, decode)

packet = EmbeddedSignaturePacket (signaturePacket 2 168 ECDSA SHA256 [] [SignatureCreationTimePacket 1013401916,IssuerPacket "36FE856F4219F1C7"] 48065 [MPI 4,MPI 11,MPI 60,MPI 69,MPI 37,MPI 33,MPI 18,MPI 72,MPI 41,MPI 36,MPI 43,MPI 41,MPI 53,MPI 9,MPI 53,MPI 35,MPI 3,MPI 40,MPI 14,MPI 79,MPI 1,MPI 4,MPI 51,MPI 23,MPI 62,MPI 62,MPI 62,MPI 7,MPI 68,MPI 51,MPI 13,MPI 49,MPI 8,MPI 64,MPI 32,MPI 50,MPI 59,MPI 17,MPI 43,MPI 12,MPI 67,MPI 5,MPI 67,MPI 5,MPI 25,MPI 63,MPI 0,MPI 53,MPI 2,MPI 36,MPI 83,MPI 39,MPI 54,MPI 65,MPI 54,MPI 35,MPI 62,MPI 63,MPI 26,MPI 4,MPI 82,MPI 57,MPI 85,MPI 71,MPI 43,MPI 77])

main = print $ decode (encode packet) == packet

如果你编译这个（在 ghc 7.4.1 上）：

ghc -O0 -fforce-recomp --make t.hs

它按预期工作（即，它打印True），但如果你像这样编译：

ghc -O1 -fforce-recomp --make t.hs

或者这个：

ghc -O2 -fforce-recomp --make t.hs

它将打印False。

我没有使用任何扩展（除了对 CPP 的微不足道的使用）或低级或不安全的调用，并且行为应该来自我的库而不是依赖项，因为它只是我的代码在此处重新编译。

【问题讨论】：

我可以在 GHC 7.4.2 中重现这个错误
当你观察到这个错误时，你使用的是二进制还是谷物？

标签： haskell ghc

【解决方案1】：

这是您的代码中的错误。考虑

MPI 63,MPI 0,MPI 53
       ^^^^^

和

instance BINARY_CLASS MPI where
    put (MPI i) = do
        put (((fromIntegral . B.length $ bytes) - 1) * 8
                + floor (logBase (2::Double) $ fromIntegral (bytes `B.index` 0))
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                + 1 :: Word16)
    putSomeByteString bytes
    where
    bytes = if B.null bytes' then B.singleton 0 else bytes'
    bytes' = B.reverse $ B.unfoldr (\x ->
                    if x == 0 then Nothing else
                           Just (fromIntegral x, x `shiftR` 8)
             ) (assertProp (>=0) i)

现在，如果我们编码MPI 0，bytes' 为空，因此bytes = B.singleton 0 和bytes `B.index` 0 为0。

但logBase 2 0 是-Infinity，而floor 仅对有限值（在目标类型的范围内）进行了明确定义。

在没有优化的情况下编译时，floor 通过decodeFloat 使用位模式。然后floor (logBase 2 0) 为所有标准的固定宽度整数类型生成 0。

通过优化，重写规则处于活动状态，floor 使用 primop double2Int#，它在 x86 上返回硬件所做的任何事情。 x86-64，即minBound :: Int，据我所知，无论位模式如何。相关代码是

floorDoubleInt :: Double -> Int
floorDoubleInt (D# x) =
    case double2Int# x of
      n | x <## int2Double# n   -> I# (n -# 1#)
        | otherwise             -> I# n

当然还有-Infinity < int2Double minBound，所以值变成minBound - 1，通常是maxBound。

当然这会导致错误的结果，因为现在 put 的“长度”对于 MPI 0 变为 0，并且放在“长度”字段之后的 0 字节被解释为“长度”的一部分下一个MPI。

【讨论】：

谢谢！我没想到floor 的行为会随着-O 而改变，但你说得对，我的假设还是有错误。
在一些地方重写规则会改变行为。大多数情况下，无论如何都没有正确的结果，例如floor 等的超出范围的值。但有时甚至在具有有意义结果的地方，例如(realToFrac :: Float -> Double) (0/0) 产生 -5.104235503814077e38 没有优化，NaN 有优化。语言报告显示realToFrac = fromRational . toRational，它产生了第一个。由于Rational 无法真正处理NaNs 和无穷大，因此在该转换中没有好的方法来处理它们并且它们被破坏了。 primop 保留了它们。
没错，@C.A.McCann，但在这种情况下，NaNs 并没有为您带来无穷无尽的乐趣。

【解决方案2】：

问题与MPI 的 BINARY_CLASS 实例有关。如果我改变了

main = do
  print packet
  print (decode (encode packet) :: SignatureSubpacket)
  print $ decode (encode packet) == packet

我看到了输出（用 -O2 编译）

EmbeddedSignaturePacket (SignaturePacket {version = 2, signature_type = 168, key_algorithm = ECDSA, hash_algorithm = SHA256, hashed_subpackets = [], unhashed_subpackets = [SignatureCreationTimePacket 1013401916,IssuerPacket "36FE856F4219F1C7"], hash_head = 48065, signature = [MPI 4,MPI 11,MPI 60,MPI 69,MPI 37,MPI 33,MPI 18,MPI 72,MPI 41,MPI 36,MPI 43,MPI 41,MPI 53,MPI 9,MPI 53,MPI 35,MPI 3,MPI 40,MPI 14,MPI 79,MPI 1,MPI 4,MPI 51,MPI 23,MPI 62,MPI 62,MPI 62,MPI 7,MPI 68,MPI 51,MPI 13,MPI 49,MPI 8,MPI 64,MPI 32,MPI 50,MPI 59,MPI 17,MPI 43,MPI 12,MPI 67,MPI 5,MPI 67,MPI 5,MPI 25,MPI 63,MPI 0,MPI 53,MPI 2,MPI 36,MPI 83,MPI 39,MPI 54,MPI 65,MPI 54,MPI 35,MPI 62,MPI 63,MPI 26,MPI 4,MPI 82,MPI 57,MPI 85,MPI 71,MPI 43,MPI 77], trailer = Chunk "\168" (Chunk "<gI<" Empty)})
EmbeddedSignaturePacket (SignaturePacket {version = 2, signature_type = 168, key_algorithm = ECDSA, hash_algorithm = SHA256, hashed_subpackets = [], unhashed_subpackets = [SignatureCreationTimePacket 1013401916,IssuerPacket "36FE856F4219F1C7"], hash_head = 48065, signature = [MPI 4,MPI 11,MPI 60,MPI 69,MPI 37,MPI 33,MPI 18,MPI 72,MPI 41,MPI 36,MPI 43,MPI 41,MPI 53,MPI 9,MPI 53,MPI 35,MPI 3,MPI 40,MPI 14,MPI 79,MPI 1,MPI 4,MPI 51,MPI 23,MPI 62,MPI 62,MPI 62,MPI 7,MPI 68,MPI 51,MPI 13,MPI 49,MPI 8,MPI 64,MPI 32,MPI 50,MPI 59,MPI 17,MPI 43,MPI 12,MPI 67,MPI 5,MPI 67,MPI 5,MPI 25,MPI 63,MPI 0,MPI 0,MPI 339782829898145924110968965855122255180100961470274369007196973863828909184332476115285611703086303618816635857833592912611149], trailer = Chunk "\168" (Chunk "<gI<" Empty)})

将您的 MPI 实例更改为更直接的实现：

newtype MPI = MPI Integer deriving (Show, Read, Eq, Ord)
instance BINARY_CLASS MPI where
  put (MPI i) = do
    put (fromIntegral $ B.length bytes :: Word16)
    putSomeByteString bytes
    where
    bytes = if B.null bytes' then B.singleton 0 else bytes'
    bytes' = B.pack . map (read . (:[])) $ show i
  get = do
    length <- fmap fromIntegral (get :: Get Word16)
    bytes <- getSomeByteString length
    return (MPI $ read $ concatMap show $ B.unpack bytes)

解决问题。

有几件事可能是问题的根源。您的代码可能是正确的（我没有以这种方式或其他方式检查过），在这种情况下，GHC 正在执行一些无效的转换，导致某处出现溢出/下溢。也有可能您的代码正在做一些不正确的事情，只有某些优化才会暴露出来。

【讨论】：