更严格的对齐类型的 VLD2 结构负载

如何解决更严格的对齐类型的 VLD2 结构负载

字节指针可以安全地传递给vld2q_u16吗？ 我最关心的是静态分析器的投诉。

uint16x8x2_t load_interleaved_shorts (const uint8_t* const ptr) {
    uint16_t* p16 = (uint16_t*)ptr; // possible undefined behavior ?
    return vld2q_u16(p16);
}

在我的例子中： 指针始终与 16 字节边界对齐。 编译器不知道指针的对齐方式。 代码必须是可移植的，并严格遵循 C90 标准。

假设： 用 vld2q_u16 替换 vld1q_u8 / vuzpq_u8 会影响性能。 编译器将标量模式优化为 vld2q_u16 的概率很小。

编辑：通过转换为空指针来抑制一些警告。 vld2q_u16((const uint16_t*)(const void*)src)

解决方法

代码必须是可移植的，并严格遵循 C90 标准。

... 加上 ARM NEON 内在函数的存在所暗示的一切！ （虽然这可能对静态分析器没有帮助）。 （相关：Is `reinterpret_cast`ing between hardware SIMD vector pointer and the corresponding type an undefined behavior? 讨论了 x86 的情况，但您的情况有点不同；您的指针已对齐）。

---

在 C 中，在指针类型之间进行转换（不取消引用）是安全的，只要您永远不会创建与其类型对齐不足的指针。您不需要编译时可见的对齐保证，您只需要永远不要实际创建一个没有 uint16_t* 对齐的 alignof(uint16_t)。

（这使得静态分析器不太可能抱怨，即使情况并非如此，除非它可以看到类似 (uint16_t*)(1 + (char*)&something_aligned) 的内容，您在其中获取对齐的地址并将其偏移一个奇数，这会保证会产生未对齐的地址。）

在实践中，针对字节可寻址机器的编译器或多或少会定义行为，即使是创建未对齐的指针也是如此。 （例如，用于未对齐加载的 Intel 内在函数取决于创建未对齐的 __m128i*。）只要您不取消引用它们，即使在允许未对齐加载的目标上，这在实践中也是不安全的；请参阅 my answer on this Q&A for an example 和涵盖其他示例的博客链接。

所以你 100% 没问题：你的代码永远不会产生未对齐的 uint16_t*，也不会直接取消引用它。

如果 ARM 具有未对齐加载的内部函数，则形成未对齐的 uint16_t* 并将其传递给函数甚至是安全的；内在 API 的存在/设计意味着以这种方式使用它是安全的。

---

其他未定义行为但您没有做的事情：

• 从技术上讲，形成一个不指向对象内部或过去端的指针是 UB，但实际上主流实现也允许这样做。

• 取消引用不指向 uint16_t* 对象的 uint16_t 是严格别名 UB。但是任何取消引用只发生在内部“函数”中，所以您不必担心严格别名规则。 （它可以将指针转换为某种特殊类型和解引用，或者可以将指针传递给内置的 __builtin_arm_whatever() 编译器。）

我假设 ARM 加载/存储内在函数的定义类似于 memcpy，能够读/写任何对象的字节。例如您可以对 vld2q_u16、int 或 double 的数组进行 char。英特尔内在函数以这种方式定义（例如 GCC/clang 使用 __attribute__((may_alias))。）如果不是，那就不安全了。

顺便说一句，char*-can-alias-anything 规则只能以一种方式起作用。是的，将 char* 指向 uint16_t 是安全的，但是如果您有一个实际的 array char buf[100]，那么这些对象肯定是 char 对象，它是 UB通过 uint16_t* 访问它们。但是，如果您只有 char*，并且只使用了除 char* 之外的另一种指针类型，那么您可以将内存视为具有其他类型的任何类型，并且每个 {{1} } 访问别名。