我有一个功能，我想为amd64架构提供一个程序集实现。为了便于讨论，我们假设它是一个
Add函数，但实际上它比这更复杂。我的程序集版本可以正常工作，但我的问题是让 godoc 正确显示。我有一种感觉，这是目前不可能的，但我想寻求建议。
更多细节：
- 该函数的汇编实现只包含几条指令。特别是，调用函数的成本是整个成本的重要组成部分。
- 它使用特殊指令 (
BMI2)，因此只能在CPUID能力检查之后使用。
实现的结构类似于这个 gist。在高水平：
- 在通用（非
amd64情况）中，该函数是通过委托给 来定义的addGeneric。 - 在
amd64函数实际上是一个变量的情况下， 如果 检查通过，最初设置为但在函数中addGeneric替换为。addAsminitcpuid
这种方法有效。但是，godoc 输出很糟糕，因为在这种
amd64情况下，函数实际上是一个变量。注意 godoc 似乎正在使用与其运行的机器相同的构建标签。我不确定godoc.org会做什么。
考虑的替代方案：
- 该
Add函数委托给addImpl. 然后我们拉一些类似addImpl的技巧来替换amd64案例。这个问题是（在我的实验中）Go 似乎无法内联调用，并且程序集现在包含在两个函数调用中。由于组件已经很小，这对性能有显着影响。 - 在这种
amd64情况下，我们定义了一个简单的函数Add，其中包含检查，并根据结果useAsm调用其中一个和。这将对性能产生更严重的影响。addGenericaddAsm
所以我想问题是：
- 有没有更好的方法来构建代码以实现我想要的性能，并让它在文档中正确显示。
- 如果没有其他选择，还有其他方法可以“欺骗”godoc吗？