Clang 是否误解了 'const' 指针说明符？
Does Clang misunderstand the 'const' pointer specifier?
在下面的代码中，我看到如果没有隐式 restrict 指针说明符，clang 无法执行更好的优化：
#include <stdint.h>
#include <stdlib.h>
#include <stdbool.h>
typedef struct {
uint32_t event_type;
uintptr_t param;
} event_t;
typedef struct
{
event_t *queue;
size_t size;
uint16_t num_of_items;
uint8_t rd_idx;
uint8_t wr_idx;
} queue_t;
static bool queue_is_full(const queue_t *const queue_ptr)
{
return queue_ptr->num_of_items == queue_ptr->size;
}
static size_t queue_get_size_mask(const queue_t *const queue_ptr)
{
return queue_ptr->size - 1;
}
int queue_enqueue(queue_t *const queue_ptr, const event_t *const event_ptr)
{
if(queue_is_full(queue_ptr))
{
return 1;
}
queue_ptr->queue[queue_ptr->wr_idx++] = *event_ptr;
queue_ptr->num_of_items++;
queue_ptr->wr_idx &= queue_get_size_mask(queue_ptr);
return 0;
}
我用 clang 版本 11.0.0 (clang-1100.0.32.5)
编译了这段代码
clang -O2 -arch armv7m -S test.c -o test.s
在反汇编文件中看到生成的代码重新读取内存：
_queue_enqueue:
.cfi_startproc
@ %bb.0:
ldrh r2, [r0, #8] ---> reads the queue_ptr->num_of_items
ldr r3, [r0, #4] ---> reads the queue_ptr->size
cmp r3, r2
itt eq
moveq r0, #1
bxeq lr
ldrb r2, [r0, #11] ---> reads the queue_ptr->wr_idx
adds r3, r2, #1
strb r3, [r0, #11] ---> stores the queue_ptr->wr_idx + 1
ldr.w r12, [r1]
ldr r3, [r0]
ldr r1, [r1, #4]
str.w r12, [r3, r2, lsl #3]
add.w r2, r3, r2, lsl #3
str r1, [r2, #4]
ldrh r1, [r0, #8] ---> !!! re-reads the queue_ptr->num_of_items
adds r1, #1
strh r1, [r0, #8]
ldrb r1, [r0, #4] ---> !!! re-reads the queue_ptr->size (only the first byte)
ldrb r2, [r0, #11] ---> !!! re-reads the queue_ptr->wr_idx
subs r1, #1
ands r1, r2
strb r1, [r0, #11] ---> !!! stores the updated queue_ptr->wr_idx once again after applying the mask
movs r0, #0
bx lr
.cfi_endproc
@ -- End function
在指针中添加 restrict 关键字后，这些不需要的重读就消失了：
int queue_enqueue(queue_t * restrict const queue_ptr, const event_t * restrict const event_ptr)
我知道在 clang 中，默认情况下 禁用严格别名。但是在这种情况下，event_ptr 指针被定义为 const 所以它的对象的内容不能被这个指针修改，因此它不会影响 queue_ptr 指向的内容（假设当对象在内存中重叠），对吗？
那么这是一个编译器优化错误还是确实存在一些奇怪的情况，当 queue_ptr 指向的对象可能会受到 event_ptr 的影响假设这个声明：
int queue_enqueue(queue_t *const queue_ptr, const event_t *const event_ptr)
顺便说一下，我尝试为 x86 目标编译相同的代码并检查了类似的优化问题。
生成的程序集withrestrict关键字，不包含重读：
_queue_enqueue:
.cfi_startproc
@ %bb.0:
ldr r3, [r0, #4]
ldrh r2, [r0, #8]
cmp r3, r2
itt eq
moveq r0, #1
bxeq lr
push {r4, r6, r7, lr}
.cfi_def_cfa_offset 16
.cfi_offset lr, -4
.cfi_offset r7, -8
.cfi_offset r6, -12
.cfi_offset r4, -16
add r7, sp, #8
.cfi_def_cfa r7, 8
ldr.w r12, [r1]
ldr.w lr, [r1, #4]
ldrb r1, [r0, #11]
ldr r4, [r0]
subs r3, #1
str.w r12, [r4, r1, lsl #3]
add.w r4, r4, r1, lsl #3
adds r1, #1
ands r1, r3
str.w lr, [r4, #4]
strb r1, [r0, #11]
adds r1, r2, #1
strh r1, [r0, #8]
movs r0, #0
pop {r4, r6, r7, pc}
.cfi_endproc
@ -- End function
加法：
在他的 的评论中与 Lundin 进行了一些讨论后，我得到的印象是可能会导致重新读取，因为编译器会假设 queue_ptr->queue 可能指向 *queue_ptr 本身。所以我将 queue_t 结构更改为包含数组而不是指针：
typedef struct
{
event_t queue[256]; // changed from pointer to array with max size
size_t size;
uint16_t num_of_items;
uint8_t rd_idx;
uint8_t wr_idx;
} queue_t;
然而，重读仍然和以前一样。我仍然不明白是什么让编译器认为 queue_t 字段可能被修改，因此需要重新读取...以下声明消除了重新读取：
int queue_enqueue(queue_t * restrict const queue_ptr, const event_t *const event_ptr)
但是为什么 queue_ptr 必须声明为 restrict 指针以防止重新读取我不明白（除非它是编译器优化 "bug"）。
P.S.
我在 clang 上也找不到任何 link 到 file/report 不会导致编译器崩溃的问题...
据我所知，是的，在您的代码中 queue_ptr pointee 的内容无法修改。这是一个优化错误吗？这是一个错失的优化机会，但我不会称之为错误。它没有 "misunderstand" const，它只是没有 have/doesn 没有进行必要的分析来确定它不能针对这种特定情况进行修改。
附带说明：queue_is_full(queue_ptr) 可以修改 *queue_ptr 的内容，即使它具有 const queue_t *const 参数，因为它可以合法地丢弃常量，因为原始对象不是常量.话虽这么说，quueue_is_full 的定义对编译器是可见和可用的，因此它可以确定它确实不可见。
queue_ptr 的 event_t 成员可以指向与 event_ptr 相同的内存。当编译器不能排除两个指针指向同一内存时，它们往往会生成效率较低的代码。所以 restrict 导致更好的代码并没有什么奇怪的。
Const 限定符并不重要，因为它们是由函数添加的，原始类型可以在其他地方修改。特别是，* const 不会添加任何内容，因为指针已经是原始指针的本地副本，因此包括调用者在内的任何人都不关心函数是否修改了该本地副本。
"Strict aliasing" 而是指编译器可以偷工减料的情况，例如假设 uint16_t* 不能指向 uint8_t* 等。但是在您的情况下，您有两个完全兼容的类型，其中一个只是包裹在一个外部结构中。
如您所知，您的代码似乎修改了数据，使 const 状态无效：
queue_ptr->num_of_items++; // this stores data in the memory
如果没有 restrict 关键字，编译器 必须 假定这两种类型可能共享相同的内存 space.
这在更新的示例中是必需的，因为 event_t 是 queue_t 的成员并且严格别名适用于：
... an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or...
在原始示例中，有多种原因可能会将类型视为别名，从而导致相同的结果（即，使用 char 指针以及类型可能被视为兼容的事实"enough" 在某些架构上（如果不是全部的话））。
因此，编译器需要重新加载内存，以避免可能的冲突。
const 关键字并没有真正进入这里，因为通过可能指向相同内存地址的指针发生了变化。
(EDIT) 为了您的方便，这里是关于访问变量的完整规则：
An object shall have its stored value accessed only by an lvalue expression that has one of the following types (88):
— a type compatible with the effective type of the object,
— a qualified version of a type compatible with the effective type of the object,
— a type that is the signed or unsigned type corresponding to the effective type of the object,
— a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,
— an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
— a character type.
(88) The intent of this list is to specify those circumstances in which an object may or may not be aliased.
P.S.
_t 后缀 由 POSIX 保留。您可以考虑使用不同的后缀。
通常的做法是对结构使用 _s，对联合使用 _u。
[说说原程序]
这是由 Clang 生成的 TBAA 元数据中的缺陷造成的。
如果你使用 -S -emit-llvm 发出 LLVM IR，你会看到（为简洁起见被删减）：
...
%9 = load i8, i8* %wr_idx, align 1, !tbaa !12
%10 = trunc i32 %8 to i8
%11 = add i8 %10, -1
%conv4 = and i8 %11, %9
store i8 %conv4, i8* %wr_idx, align 1, !tbaa !12
br label %return
...
!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 1, !"min_enum_size", i32 4}
!2 = !{!"clang version 10.0.0 (/home/chill/src/llvm-project 07da145039e1a6a688fb2ac2035b7c062cc9d47d)"}
!3 = !{!4, !9, i64 8}
!4 = !{!"queue", !5, i64 0, !8, i64 4, !9, i64 8, !6, i64 10, !6, i64 11}
!5 = !{!"any pointer", !6, i64 0}
!6 = !{!"omnipotent char", !7, i64 0}
!7 = !{!"Simple C/C++ TBAA"}
!8 = !{!"int", !6, i64 0}
!9 = !{!"short", !6, i64 0}
!10 = !{!4, !8, i64 4}
!11 = !{!4, !5, i64 0}
!12 = !{!4, !6, i64 11}
查看 TBAA 元数据 !4：这是 queue_t 的类型描述符（顺便说一句，我向结构添加了名称，例如 typedef struct queue ...）您可能会在那里看到空字符串）。描述中的每个元素都对应struct字段，看!5，也就是event_t *queue字段：是"any pointer"！在这一点上，我们已经丢失了有关指针实际类型的所有信息，这告诉我编译器会假设通过该指针进行的写入可以修改任何内存对象。
也就是说，TBAA 元数据有一种新形式，它更精确（仍然有不足之处，但稍后......）
用-Xclang -new-struct-path-tbaa编译原程序。我的确切命令行是（并且我已经包括 stddef.h 而不是 stdlib.h 因为那个开发构建没有 libc）：
./bin/clang -I lib/clang/10.0.0/include/ -target armv7m-eabi -O2 -Xclang -new-struct-path-tbaa -S queue.c
生成的程序集是（同样，剪掉了一些绒毛）：
queue_enqueue:
push {r4, r5, r6, r7, lr}
add r7, sp, #12
str r11, [sp, #-4]!
ldrh r3, [r0, #8]
ldr.w r12, [r0, #4]
cmp r12, r3
bne .LBB0_2
movs r0, #1
ldr r11, [sp], #4
pop {r4, r5, r6, r7, pc}
.LBB0_2:
ldrb r2, [r0, #11] ; load `wr_idx`
ldr.w lr, [r0] ; load `queue` member
ldrd r6, r1, [r1] ; load data pointed to by `event_ptr`
add.w r5, lr, r2, lsl #3 ; compute address to store the event
str r1, [r5, #4] ; store `param`
adds r1, r3, #1 ; increment `num_of_items`
adds r4, r2, #1 ; increment `wr_idx`
str.w r6, [lr, r2, lsl #3] ; store `event_type`
strh r1, [r0, #8] ; store new value for `num_of_items`
sub.w r1, r12, #1 ; compute size mask
ands r1, r4 ; bitwise and size mask with `wr_idx`
strb r1, [r0, #11] ; store new value for `wr_idx`
movs r0, #0
ldr r11, [sp], #4
pop {r4, r5, r6, r7, pc}
看起来不错，不是吗！ :D
我之前提到 "new struct path" 存在缺陷，但为此：在邮件列表中。
PS。恐怕在这种情况下没有一般的教训可以吸取。原则上，能够为编译器提供的信息越多越好：诸如 restrict、强类型（不是无端强制转换、类型双关等）、相关函数和变量属性……但不在此列在这种情况下，原始程序已经包含了所有必要的信息。这只是一个编译器缺陷，解决这些问题的最佳方法是提高认识：在邮件列表上询问 and/or 文件错误报告。
在下面的代码中，我看到如果没有隐式 restrict 指针说明符，clang 无法执行更好的优化：
#include <stdint.h>
#include <stdlib.h>
#include <stdbool.h>
typedef struct {
uint32_t event_type;
uintptr_t param;
} event_t;
typedef struct
{
event_t *queue;
size_t size;
uint16_t num_of_items;
uint8_t rd_idx;
uint8_t wr_idx;
} queue_t;
static bool queue_is_full(const queue_t *const queue_ptr)
{
return queue_ptr->num_of_items == queue_ptr->size;
}
static size_t queue_get_size_mask(const queue_t *const queue_ptr)
{
return queue_ptr->size - 1;
}
int queue_enqueue(queue_t *const queue_ptr, const event_t *const event_ptr)
{
if(queue_is_full(queue_ptr))
{
return 1;
}
queue_ptr->queue[queue_ptr->wr_idx++] = *event_ptr;
queue_ptr->num_of_items++;
queue_ptr->wr_idx &= queue_get_size_mask(queue_ptr);
return 0;
}
我用 clang 版本 11.0.0 (clang-1100.0.32.5)
编译了这段代码clang -O2 -arch armv7m -S test.c -o test.s
在反汇编文件中看到生成的代码重新读取内存：
_queue_enqueue:
.cfi_startproc
@ %bb.0:
ldrh r2, [r0, #8] ---> reads the queue_ptr->num_of_items
ldr r3, [r0, #4] ---> reads the queue_ptr->size
cmp r3, r2
itt eq
moveq r0, #1
bxeq lr
ldrb r2, [r0, #11] ---> reads the queue_ptr->wr_idx
adds r3, r2, #1
strb r3, [r0, #11] ---> stores the queue_ptr->wr_idx + 1
ldr.w r12, [r1]
ldr r3, [r0]
ldr r1, [r1, #4]
str.w r12, [r3, r2, lsl #3]
add.w r2, r3, r2, lsl #3
str r1, [r2, #4]
ldrh r1, [r0, #8] ---> !!! re-reads the queue_ptr->num_of_items
adds r1, #1
strh r1, [r0, #8]
ldrb r1, [r0, #4] ---> !!! re-reads the queue_ptr->size (only the first byte)
ldrb r2, [r0, #11] ---> !!! re-reads the queue_ptr->wr_idx
subs r1, #1
ands r1, r2
strb r1, [r0, #11] ---> !!! stores the updated queue_ptr->wr_idx once again after applying the mask
movs r0, #0
bx lr
.cfi_endproc
@ -- End function
在指针中添加 restrict 关键字后，这些不需要的重读就消失了：
int queue_enqueue(queue_t * restrict const queue_ptr, const event_t * restrict const event_ptr)
我知道在 clang 中，默认情况下 禁用严格别名。但是在这种情况下，event_ptr 指针被定义为 const 所以它的对象的内容不能被这个指针修改，因此它不会影响 queue_ptr 指向的内容（假设当对象在内存中重叠），对吗？
那么这是一个编译器优化错误还是确实存在一些奇怪的情况，当 queue_ptr 指向的对象可能会受到 event_ptr 的影响假设这个声明：
int queue_enqueue(queue_t *const queue_ptr, const event_t *const event_ptr)
顺便说一下，我尝试为 x86 目标编译相同的代码并检查了类似的优化问题。
生成的程序集withrestrict关键字，不包含重读：
_queue_enqueue:
.cfi_startproc
@ %bb.0:
ldr r3, [r0, #4]
ldrh r2, [r0, #8]
cmp r3, r2
itt eq
moveq r0, #1
bxeq lr
push {r4, r6, r7, lr}
.cfi_def_cfa_offset 16
.cfi_offset lr, -4
.cfi_offset r7, -8
.cfi_offset r6, -12
.cfi_offset r4, -16
add r7, sp, #8
.cfi_def_cfa r7, 8
ldr.w r12, [r1]
ldr.w lr, [r1, #4]
ldrb r1, [r0, #11]
ldr r4, [r0]
subs r3, #1
str.w r12, [r4, r1, lsl #3]
add.w r4, r4, r1, lsl #3
adds r1, #1
ands r1, r3
str.w lr, [r4, #4]
strb r1, [r0, #11]
adds r1, r2, #1
strh r1, [r0, #8]
movs r0, #0
pop {r4, r6, r7, pc}
.cfi_endproc
@ -- End function
加法：
在他的 queue_ptr->queue 可能指向 *queue_ptr 本身。所以我将 queue_t 结构更改为包含数组而不是指针：
typedef struct
{
event_t queue[256]; // changed from pointer to array with max size
size_t size;
uint16_t num_of_items;
uint8_t rd_idx;
uint8_t wr_idx;
} queue_t;
然而，重读仍然和以前一样。我仍然不明白是什么让编译器认为 queue_t 字段可能被修改，因此需要重新读取...以下声明消除了重新读取：
int queue_enqueue(queue_t * restrict const queue_ptr, const event_t *const event_ptr)
但是为什么 queue_ptr 必须声明为 restrict 指针以防止重新读取我不明白（除非它是编译器优化 "bug"）。
P.S.
我在 clang 上也找不到任何 link 到 file/report 不会导致编译器崩溃的问题...
据我所知，是的，在您的代码中 queue_ptr pointee 的内容无法修改。这是一个优化错误吗？这是一个错失的优化机会，但我不会称之为错误。它没有 "misunderstand" const，它只是没有 have/doesn 没有进行必要的分析来确定它不能针对这种特定情况进行修改。
附带说明：queue_is_full(queue_ptr) 可以修改 *queue_ptr 的内容，即使它具有 const queue_t *const 参数，因为它可以合法地丢弃常量，因为原始对象不是常量.话虽这么说，quueue_is_full 的定义对编译器是可见和可用的，因此它可以确定它确实不可见。
queue_ptr 的 event_t 成员可以指向与 event_ptr 相同的内存。当编译器不能排除两个指针指向同一内存时，它们往往会生成效率较低的代码。所以 restrict 导致更好的代码并没有什么奇怪的。
Const 限定符并不重要，因为它们是由函数添加的，原始类型可以在其他地方修改。特别是，* const 不会添加任何内容，因为指针已经是原始指针的本地副本，因此包括调用者在内的任何人都不关心函数是否修改了该本地副本。
"Strict aliasing" 而是指编译器可以偷工减料的情况，例如假设 uint16_t* 不能指向 uint8_t* 等。但是在您的情况下，您有两个完全兼容的类型，其中一个只是包裹在一个外部结构中。
如您所知，您的代码似乎修改了数据，使 const 状态无效：
queue_ptr->num_of_items++; // this stores data in the memory
如果没有 restrict 关键字，编译器 必须 假定这两种类型可能共享相同的内存 space.
这在更新的示例中是必需的，因为 event_t 是 queue_t 的成员并且严格别名适用于：
... an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or...
在原始示例中，有多种原因可能会将类型视为别名，从而导致相同的结果（即，使用 char 指针以及类型可能被视为兼容的事实"enough" 在某些架构上（如果不是全部的话））。
因此，编译器需要重新加载内存，以避免可能的冲突。
const 关键字并没有真正进入这里，因为通过可能指向相同内存地址的指针发生了变化。
(EDIT) 为了您的方便，这里是关于访问变量的完整规则：
An object shall have its stored value accessed only by an lvalue expression that has one of the following types (88):
— a type compatible with the effective type of the object,
— a qualified version of a type compatible with the effective type of the object,
— a type that is the signed or unsigned type corresponding to the effective type of the object,
— a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object,
— an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
— a character type.
(88) The intent of this list is to specify those circumstances in which an object may or may not be aliased.
P.S.
_t 后缀 由 POSIX 保留。您可以考虑使用不同的后缀。
通常的做法是对结构使用 _s，对联合使用 _u。
[说说原程序]
这是由 Clang 生成的 TBAA 元数据中的缺陷造成的。
如果你使用 -S -emit-llvm 发出 LLVM IR，你会看到（为简洁起见被删减）：
...
%9 = load i8, i8* %wr_idx, align 1, !tbaa !12
%10 = trunc i32 %8 to i8
%11 = add i8 %10, -1
%conv4 = and i8 %11, %9
store i8 %conv4, i8* %wr_idx, align 1, !tbaa !12
br label %return
...
!0 = !{i32 1, !"wchar_size", i32 4}
!1 = !{i32 1, !"min_enum_size", i32 4}
!2 = !{!"clang version 10.0.0 (/home/chill/src/llvm-project 07da145039e1a6a688fb2ac2035b7c062cc9d47d)"}
!3 = !{!4, !9, i64 8}
!4 = !{!"queue", !5, i64 0, !8, i64 4, !9, i64 8, !6, i64 10, !6, i64 11}
!5 = !{!"any pointer", !6, i64 0}
!6 = !{!"omnipotent char", !7, i64 0}
!7 = !{!"Simple C/C++ TBAA"}
!8 = !{!"int", !6, i64 0}
!9 = !{!"short", !6, i64 0}
!10 = !{!4, !8, i64 4}
!11 = !{!4, !5, i64 0}
!12 = !{!4, !6, i64 11}
查看 TBAA 元数据 !4：这是 queue_t 的类型描述符（顺便说一句，我向结构添加了名称，例如 typedef struct queue ...）您可能会在那里看到空字符串）。描述中的每个元素都对应struct字段，看!5，也就是event_t *queue字段：是"any pointer"！在这一点上，我们已经丢失了有关指针实际类型的所有信息，这告诉我编译器会假设通过该指针进行的写入可以修改任何内存对象。
也就是说，TBAA 元数据有一种新形式，它更精确（仍然有不足之处，但稍后......）
用-Xclang -new-struct-path-tbaa编译原程序。我的确切命令行是（并且我已经包括 stddef.h 而不是 stdlib.h 因为那个开发构建没有 libc）：
./bin/clang -I lib/clang/10.0.0/include/ -target armv7m-eabi -O2 -Xclang -new-struct-path-tbaa -S queue.c
生成的程序集是（同样，剪掉了一些绒毛）：
queue_enqueue:
push {r4, r5, r6, r7, lr}
add r7, sp, #12
str r11, [sp, #-4]!
ldrh r3, [r0, #8]
ldr.w r12, [r0, #4]
cmp r12, r3
bne .LBB0_2
movs r0, #1
ldr r11, [sp], #4
pop {r4, r5, r6, r7, pc}
.LBB0_2:
ldrb r2, [r0, #11] ; load `wr_idx`
ldr.w lr, [r0] ; load `queue` member
ldrd r6, r1, [r1] ; load data pointed to by `event_ptr`
add.w r5, lr, r2, lsl #3 ; compute address to store the event
str r1, [r5, #4] ; store `param`
adds r1, r3, #1 ; increment `num_of_items`
adds r4, r2, #1 ; increment `wr_idx`
str.w r6, [lr, r2, lsl #3] ; store `event_type`
strh r1, [r0, #8] ; store new value for `num_of_items`
sub.w r1, r12, #1 ; compute size mask
ands r1, r4 ; bitwise and size mask with `wr_idx`
strb r1, [r0, #11] ; store new value for `wr_idx`
movs r0, #0
ldr r11, [sp], #4
pop {r4, r5, r6, r7, pc}
看起来不错，不是吗！ :D
我之前提到 "new struct path" 存在缺陷，但为此：在邮件列表中。
PS。恐怕在这种情况下没有一般的教训可以吸取。原则上，能够为编译器提供的信息越多越好：诸如 restrict、强类型（不是无端强制转换、类型双关等）、相关函数和变量属性……但不在此列在这种情况下，原始程序已经包含了所有必要的信息。这只是一个编译器缺陷，解决这些问题的最佳方法是提高认识：在邮件列表上询问 and/or 文件错误报告。