当与ARM目标上的数字文字组合时，Clang是否会将短路提升为整数？

在桌面上使用GCC并打开

-Wconversion

警告时，很明显

short

s在数字文本的数学运算期间会升级为

int

s：

unsigned short i = 10; // Obviously truncates to short immediately
unsigned short j = 30; // Same here

i = j + 2; // Warnings imply j gets promoted to int here, demands cast

在ARM目标上，规则是“短路总是更快”，但在几乎任何数学运算（尤其是文字运算）中，它们都会被提升到

int

s进行运算，这是真的吗

如果是这样，除了让编译器帮助您检查边界是否合理之外，还有什么理由使用

short

s吗？我没有处理大量的短裤，所以存储空间似乎不是问题（或者是吗？）

注意。这是音频处理，所以我不是为了它而优化，我确实需要考虑这一点

在ARM目标上，规则是“短路总是更快”，但在几乎任何数学运算（尤其是文字）期间，它们是否仍会被提升为整数进行运算

对于大多数运算符，

short

操作数由于整数提升规则而提升为

int

比如说

i = j + 2;  // j is promoted to int because of integer promotion

而且

i = i + j; // i and j are promoted to int in the + expression 

在手臂目标上，规则是“短裤总是更快”

---

在ARM上，

short

是

16

-位，但ARM字大小是

32

-位，因此此语句是错误的

short

或

char

需要符号扩展或零扩展，速度较慢

short

可以用来节省内存，但对于性能而言，

int

或

long

更快。

算术运算符不接受小于

int

的类型作为参数。

形式上，该语言要求提升小于

int

的类型（到

int

或

无符号int

）在大多数算术运算之前。这意味着在您的示例中，

j

被提升到

int

，加法在

int

中执行，结果通过赋值转换回

short

---

但是，如果编译器不会改变程序的可观察行为，那么它可以自由地省略这些转换。因为这种情况下的结果被转换回

short

，这在这里适用-编译器可以发出一条指令，直接执行

short

大小的加法，这是合法的。如果hat将在目标平台上执行得更快，您可以预期

clang

会这样做。

+

运算符将操作数提升为int（例如，如果其

char

，或leas then

sizeof（int）

），您在哪里看到过“短操作数总是更快的？”关于ARM？这显然是胡说八道，因为每次从32位寄存器移动它们时，它们都必须被截断为16位。