【发布时间】：2021-08-11 16:54:42
【问题描述】：
是否有符合标准的方法来检测C标准库中的函数是否通过intrinsic/builtin实现？
我非常有信心我可以实现比标准库针对特定调用站点提供的函数更好的代码，即使只是因为函数调用开销。但是如果有问题的函数是通过intrinsic/builtin实现的，就没有函数调用开销可以击败，所以尝试是愚蠢的。
如果有办法，我觉得它不会简单，因为它可能因呼叫站点而异。例如，将恒定长度传递给memcpy 可能会为编译器提供生成内联代码的绝佳机会，但可变长度可能提供的机会较少。我想最好的提示可能是三个值之一，“总是”、“从不”或“有时”。这对我来说已经足够了。
只要符合标准，如何实现的细节都可以协商。该标准的版本甚至是可以协商的，因为这是可测试的，如果该问题对于该标准的早期版本无法回答，我很乐意做出最安全的假设。但当然，最好在编译时这样做。
（经过编辑以包含具体细节，以便更容易思考，即使这些细节无关紧要）
假设memcpy 确实是有问题的函数，并且我们知道长度始终是可变的，因为它被传递给调用memcpy 的函数，但我们也知道长度通常为1。
调用库的开销肯定会支配if (1==length) 和*dst = *src;。所以问题是 1 实际上是多少频率，这是一个只有我能回答的问题，以及是否可以消除实现调用库的任何可能性。
这个问题不是关于是否可以编写比memcpy 或任何其他标准库函数更快的函数。对此有很多问题，而这不是其中之一。
【问题讨论】：
-
不，没有这样的方法。您必须查看您的实施规范。此外，我还没有看到对
memcpy()的内联调用，即使使用恒定大小参数也是如此。另外，您指的“函数调用开销”到底是什么？ -
C 标准甚至没有“内在/内置”的概念。
-
即使它是通过内置实现的，这些内置也可能会退回到对某些输入的函数调用。确实，您会希望以两种方式编译代码，然后检查程序集以查看是否存在函数调用。
-
“我非常有信心我可以实现性能更好的代码......” --> 当心Is premature optimization really the root of all evil?.
-
@SergeyA：
memcpy已有效内联到单个mov：gcc.godbolt.org/z/eqosd9Mv3
标签： c standards c-standard-library