铛（LLVM）内联汇编 - 无用泄漏/重载多重约束 [英] clang (LLVM) inline assembly - multiple constraints with useless spills / reloads

问题描述

铛/ GCC ：有些内联汇编操作数可以得到满意的多重约束，如RM，当一个操作数可以得到满意用一个寄存器或内存位置。作为一个例子，在64×64 = 128位的乘法

clang / gcc : Some inline assembly operands can be satisfied with multiple constraints, e.g., "rm", when an operand can be satisfied with a register or memory location. As an example, the 64 x 64 = 128 bit multiply:

__asm__ ("mulq %q3" : "=a" (rl), "=d" (rh) : "%0" (x), "rm" (y) : "cc")

生成的code能够选择参数的内存限制 3 ，如果我们注册饿死，避免溢出这将是罚款。显然有比IA32上的x86-64少寄存器pressure。但是，大会片断产生的（由铛）是：

The generated code appears to choose a memory constraint for argument 3, which would be fine if we were register starved, to avoid a spill. Obviously there's less register pressure on x86-64 than on IA32. However, the assembly snippet generated (by clang) is:

    movq    %rcx, -8(%rbp)
    ## InlineAsm Start
    mulq -8(%rbp)
    ## InlineAsm End

选择一个内存限制显然是毫无意义的！改变约束为：R（Y），但是（强制寄存器），我们得到：

Choosing a memory constraint is clearly pointless! Changing the constraint to: "r" (y), however (forcing a register) we get:

    ## InlineAsm Start
    mulq %rcx
    ## InlineAsm End

预期。这些结果对铛/ LLVM 3.2（目前X code释放）。第一个问题：？为什么会选择铛在这种情况下，低效率的约束

其次，有较少广泛使用，以逗号分隔，的多个可选的约束语法：结果
R，M（Y），其中应的评估各方案的成本，并选择结果是减少拷贝的人。这似乎工作，的但铛简单地选择第一个的 - 为明证：M，R（Y）

Secondly, there is the less widely used, comma-separated, multiple alternative constraint syntax:
"r,m" (y), which should evaluate the costs of each alternative, and choose the one that results in less copying. This appears to work, but clang simply chooses the first - as evidenced by: "m,r" (y)

我可以简单地删除M替代的约束，但这并不EX preSS可能存在的法律操作数的范围。这使我的第二个问题：让这些问题得到解决或3.3至少承认我试图寻找通过LLVM开发档案，但我宁愿进一步征求了一些答案之前不必要的限制的约束？ ，或加入项目的讨论，等等。

I could simply drop the "m" alternative constraints, but this doesn't express the range of possible legal operands. This brings me to the second question: Have these issues been resolved or at least acknowledged in 3.3? I've tried looking through LLVM dev archives, but I'd rather solicit some answers before unnecessarily restricting constraints further, or joining project discussions, etc.

20160612 ：我们到LLVM 3.8.0现在（以及GCC-6.1），而乔布斯只知道苹果公司的X code LLVM对应，考虑到他们的还是的似乎无法拔出自己的手指并正确实施TLS - 请纠正我，如果我错了。我会看看最新的结果...

20160612: we're up to LLVM 3.8.0 now (as well as gcc-6.1), and Jobs only knows what Apple's Xcode LLVM corresponds to, considering they still can't seem pull their finger out and implement TLS properly - please correct me if I'm wrong. I'll have a look at the latest results...

推荐答案

我对的从开发商之一CFE-dev的（铛前端开发者列表）：

I had a response on the cfe-dev (clang front end developers' list) from one of the developers:

目前LLVM始终溢出，以简化RM的限制
  在后端内联汇编处理（你可以问上llvmdev，如果你想
  细节）。我不知道任何计划在不久的将来，以解决这个问题。

LLVM currently always spills "rm" constraints in order to simplify the handling of inline asm in the backend (you can ask on llvmdev if you want details). I don't know of any plans to fix this in the near future.

所以这显然是一个已知的问题。一个铿锵的目标是要正确处理gcc的内嵌汇编语法，除其他的扩展，它在这种情况下 - 只是没有非常有效。总之，这是不是一个错误，本身。

So it's clearly a 'known' issue. One of the goals of clang is to correctly handle gcc's inline assembly syntax, amongst other extensions, which it does in this case - just not very efficiently. In short, this isn't a bug, per se.

由于这是不是一个错误，我将继续与R，M约束语法。我想这是最好的折衷现在。 GCC 将选择最好的 - presumably寄存器，其中可能的 - 铛将强制使用寄存器忽略逗号之后再选择。如果不出意外，它依然preserves大会声明的语义意图的，即描述的可能的约束，即使它们被忽略。

Since this isn't a bug, I'm going to continue with the "r,m" constraint syntax. I figure that this is the best compromise for now. gcc will choose the best - presumably a register where possible - and clang will force the use of a register by ignoring further options after the comma. If nothing else, it still preserves the semantic intent of the assembly statement, i.e., describing possible constraints, even if they are ignored.

最后需要说明的（20130715）：这个特殊的例子使用R，M约束在一个位置，将无法编译 - 我们必须提供一个替代的约束比赛每个，例如，

A final note (20130715) : This particular example will not compile using the "r,m" constraint in a single position - we would have to supply an alternative constraint match for each, e.g.,

: "=a,a" (rl), "=d,d" (rh) : "%0,0" (x), "r,m" (y)

这是的需要的与GCC多个可选的约束。但是我们进入其中，GCC已经知道，表现出以往的错误领土 - 这是否是真正的 4.8.1 ，我不知道。锵工作的没有的在其他方面的限制，这是与海湾合作委员会的语法不兼容的替代品，因此必须被认为是一个错误。

This is required for multiple alternative constraints with GCC. But we're getting into territory where GCC has been known to exhibit bugs in the past - whether or not this is true as of 4.8.1, I don't know. Clang works without the alternatives in the other constraints, which is incompatible with GCC syntax, and must therefore be considered a bug.

如果性能是至关重要的，使用R，否则，坚持与RM，也许铛会在未来解决这个问题，即使它有利于GCC。

If performance is critical, use "r", otherwise, stick with "rm" and maybe clang will address this in the future, even as it benefits GCC.

这篇关于铛（LLVM）内联汇编 - 无用泄漏/重载多重约束的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！