Ios 苹果的优化缺陷'；是LLVM，还是代码中的bug？

我有一些iOS C++代码，在本地机器上正确编译（LLVM 9），但在我的构建服务器（LLVM 10）上编译不正确。该项目是通过CMake生成的（两者的版本相同），因此正在编译的代码是相同的，具有相同的编译器设置

在最终意识到LLVM10版本上没有更新某些关键值之后，我调查了程序集，发现它完全跳过了部分代码

void                    SceneDisplay::SetSize(const math::Vec2 &Size)
{
    m_Size = Size;

    m_ScreenWidth = int(m_Size.x * float(GraphicsUtil::WIDTH));
    m_ScreenHeight = int(m_Size.y * float(GraphicsUtil::HEIGHT));

    UpdateOffsetScale();
}

在类构造函数中将m_Size初始化为1.0,1.0。使用LLVM9，这一切都很好——使用LLVM10，我们可以进行以下分解：

    pushq    %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register %rbp
    subq    $16, %rsp
    movq    __ZN12GraphicsUtil6HEIGHTE@GOTPCREL(%rip), %rax        
    movq    __ZN12GraphicsUtil5WIDTHE@GOTPCREL(%rip), %rcx        
    movq    %rdi, -8(%rbp)                        
    movq    %rsi, -16(%rbp)
    movq    -8(%rbp), %rsi
Ltmp2347:
    movq    -16(%rbp), %rdi
    movq    (%rdi), %rdi
    movq    %rdi, 56(%rsi)
    movl    (%rcx), %edx
    movl    %edx, 12(%rsi)
    movl    (%rax), %edx
    movl    %edx, 16(%rsi)
    movq    (%rsi), %rax
    movq    %rsi, %rdi
    callq    *136(%rax)
    addq    $16, %rsp
    popq    %rbp
    retq

正如您所看到的，两个成员变量的赋值是完全“优化”的，只需假设m_Size.x和m_Size.y为1.0，这样就可以复制GraphicsUtil:：WIDTH和HEIGHT的值

我修正了这个问题，将代码改为使用“Size”而不是“m_Size”来分配这些任务，并且为了以防万一，让它们变得易变。但是我想知道这里是不是有一个合法的编译器错误或者我遗漏了什么

编辑：应该注意，m_大小几乎从不为1.0,1.0

Edit2：在我的机器上生成的任务的正确程序集（虽然不同的拱门，但现在无法获得与上面相同的拱门）

---

在做了一个最小的测试用例之后，我能够确认这肯定是一个编译器错误

条件：没有其他代码修改m_大小，m_大小已初始化

math:：Vec2 m_大小{1.0,1.0}。它在10.0之前我能找到的所有LLVM版本上都能完美工作，似乎在那个版本上出现了某种回归

已提交给苹果的LLVM团队和LLVM.org

谢谢你的评论。
在做了一个最小的测试用例之后，我能够确认这肯定是一个编译器错误

条件：没有其他代码修改m_大小，m_大小已初始化
math:：Vec2 m_大小{1.0,1.0}。它在10.0之前我能找到的所有LLVM版本上都能完美工作，似乎在那个版本上出现了某种回归

已提交给苹果的LLVM团队和LLVM.org

感谢您的评论。
在程序集中未看到任何
1
s，待定。但是确实可以看到像
__ZN12GraphicsUtil6HEIGHTE@GOTPCREL
。怎么了？如果你看C++原件，它应该乘以MySig.x和MySig.y.这些值几乎从来都不是1.0，但由于错误的优化，假设它们都是1.0-这意味着加载值并“乘以1.0”，然后存储在结果中，即它只是加载并存储值，而不是执行代码中实际编写的操作。啊，对。那么，如何声明
GraphicsUtil:：WIDTH
？它是一个静态浮点。我现在无法访问相同的反汇编，但我已经为相同的任务修改了正确的arm64程序集。我认为您应该做的是为LLVM（嗯，苹果版本）编写一份错误报告。一个小的，独立的东西，要么会在你自己身上引起一个无聊的时刻，要么会给苹果一个复制和修复这个问题的方法。IMO两种结果的概率均大于10%。在组件中未看到任何
1
s，待定。但是确实可以看到像
__ZN12GraphicsUtil6HEIGHTE@GOTPCREL
。怎么了？如果你看C++原件，它应该乘以MySig.x和MySig.y.这些值几乎从来都不是1.0，但由于错误的优化，假设它们都是1.0-这意味着加载值并“乘以1.0”，然后存储在结果中，即它只是加载并存储值，而不是执行代码中实际编写的操作。啊，对。那么，如何声明
GraphicsUtil:：WIDTH
？它是一个静态浮点。我现在无法访问相同的反汇编，但我已经为相同的任务修改了正确的arm64程序集。我认为您应该做的是为LLVM（嗯，苹果版本）编写一份错误报告。一个小的，独立的东西，要么会在你自己身上引起一个无聊的时刻，要么会给苹果一个复制和修复这个问题的方法。IMO这两种结果的可能性都大于10%。对于其他人来说，这有助于提供一个bug报告的链接（至少llvm.org上的应该是公开的）。将在一点时间内更新帖子-我有点虚张声势，因为llvm.org提交bug的规则稍微复杂一些，仍在努力：）苹果似乎没有公开bug列表。对于其他人来说，这有助于提供一个bug报告的链接（至少llvm.org上的那个应该是公开的）。将在一点时间内更新帖子-我有点虚张声势，因为llvm.org有更复杂的提交bug的规则，仍然在处理：）苹果似乎没有公开bug列表。
    str         x8, [x0, #56]
    lsr         x9, x8, #32
    fmov        s0, w8
    adrp        x8, __ZN12GraphicsUtil5WIDTHE@GOTPAGE
    ldr         x8, [x8, __ZN12GraphicsUtil5WIDTHE@GOTPAGEOFF]
    ldr         s1, [x8]
    ucvtf       s1, s1
    fmul        s0, s0, s1
    fcvtzs      w8, s0
    str         w8, [x0, #12]
    fmov        s0, w9
    adrp        x8, __ZN12GraphicsUtil6HEIGHTE@GOTPAGE
    ldr         x8, [x8, __ZN12GraphicsUtil6HEIGHTE@GOTPAGEOFF]
    ldr         s1, [x8]
    ucvtf       s1, s1
    fmul        s0, s0, s1
    fcvtzs      w8, s0
    str         w8, [x0, #16]