delphi - 乘法整数溢出 - 编译器错误？

Question

考虑以下代码，这是一种基于当前时间生成整数标识符的简单方法，其中 Result 是 Int64:

  dtRef  := Now;

  Result := YearOf(dtRef)   * 100000000000 +
            MonthOf(dtRef)  * 1000000000   +
            DayOf(dtRef)    * 10000000     +
            HourOf(dtRef)   * 100000       +
            MinuteOf(dtRef) * 1000         +
            SecondOf(dtRef) * 10           +
            m_nLastTaskID;

例如，今天生成的 ID 为 20190503163412142 (< 2^55)，完全在 Int64 (2^63 - 1) 的范围内。

但是，这会在柏林和里约上造成整数溢出。它编译为:

MyUnitU.pas.580: Result := YearOf(dtRef)   * 100000000000 +
007BCEAE 6A17             push $17
007BCEB0 6800E87648       push $4876e800
007BCEB5 FF75EC           push dword ptr [ebp-$14]
007BCEB8 FF75E8           push dword ptr [ebp-$18]
007BCEBB E84CF2D3FF       call YearOf
007BCEC0 0FB7C0           movzx eax,ax
007BCEC3 33D2             xor edx,edx
007BCEC5 E8FA0AC5FF       call @_llmulo
007BCECA 7105             jno $007bced1
007BCECC E83FC7C4FF       call @IntOver
007BCED1 52               push edx
007BCED2 50               push eax
007BCED3 FF75EC           push dword ptr [ebp-$14]
007BCED6 FF75E8           push dword ptr [ebp-$18]
007BCED9 E852F2D3FF       call MonthOf
007BCEDE 0FB7C0           movzx eax,ax
007BCEE1 BA00CA9A3B       mov edx,$3b9aca00
007BCEE6 F7E2             mul edx
007BCEE8 7105             jno $007bceef
007BCEEA E821C7C4FF       call @IntOver

第一个乘法使用 _llmulo(64 位有符号乘法，带溢出检查)，而第二个乘法使用普通的 mul。下面是我评论的第二个乘法:

007BCED9 E852F2D3FF       call MonthOf       // Put the month (word) on AX
007BCEDE 0FB7C0           movzx eax,ax       // EAX <- AX as a double word
007BCEE1 BA00CA9A3B       mov edx,$3b9aca00  // EDX <- 1000000000
007BCEE6 F7E2             mul edx            // EDX:EAX <- EAX * EDX
007BCEE8 7105             jno $007bceef      // Jump if overflow flag not set
007BCEEA E821C7C4FF       call @IntOver      // Called (overflow flag set!)

我认为由于 this bug report 在 _llmulo 上设置了溢出标志关于 _llmulo 的问题(源代码中还有一条评论指出溢出检查不起作用)。

但是，在调试时，溢出标志实际上是在 mul 之后设置的!根据Intel's manual :

The OF and CF flags are set to 0 if the upper half of the result is 0; otherwise, they are set to 1.

在本例中，mul 之后 EDX 为 0x2A05F200，EAX 为 0x00000001 ，所以看来 OF 标志确实应该被设置。问题是，mul 这里正确吗？这是编译器的问题还是我的代码的问题？

我注意到，如果我在乘以 1000 之前将 MonthOf 等的结果归因于 Int64 变量...，所有乘法都使用 _llmulo 完成，并且工作正常。

Answer 1

mul的 OF/CF 输出并不意味着 64 位结果溢出；这不可能。这意味着结果不适合低 32，这对于使用具有特殊情况的结果的代码可能很有用，对于适合一个寄存器的数字来说速度更快。如果是32位mul产生edx=0x2A05F200 ，那么是的，上半部分非零，所以 CF=OF=1 是正确的。 (顺便说一句，https://www.felixcloutier.com/x86/mul 包含英特尔第 2 卷 PDF 的 HTML 摘录)。

<小时/>

如果 Delphi 类似于 C，100000000000已经是 Int64 因为它太大而无法容纳 32 位整数。因此编译器执行 64x64 => 64 位乘法，检查 64 位结果是否溢出。

但是1000000000 确实适合 32 位整数，因此您的源代码正在执行 32 x 32 => 32 位乘法，并且编译器正确检查在将 32 位结果提升为 64 以便与其他 64 位结果相加之前，32 位结果会发生溢出。

I noticed that if I attribute the result of MonthOf etc to Int64 variables before multiplying by 1000..., all multiplications are done using _llmulo and it works fine.

这是一个错过的优化，也许启用优化后，编译器会注意到它实际上可以仅使用 mul 将后面的 64x64 => 64 乘法简化为 32x32 => 64或imul ，因为已知输入很窄。

<小时/>

C 编译器会进行此优化，例如(on Godbolt)

uint64_t foo_widen(uint32_t a, uint32_t b) {
    return a * (uint64_t)b;
}

# gcc9.1 -m32 -O3
foo_widen:
    mov     eax, DWORD PTR [esp+8]    # load 2nd arg
    mul     DWORD PTR [esp+4]         # multiply into EDX:EAX return value
    ret