c++ - 指针转换是否昂贵？

Question

指针转换被认为是昂贵的吗？ (例如，转换一个指针/地址需要多少个 CPU 周期)，尤其是当你必须经常这样做时，例如(只是一个显示频率范围的例子，我知道对于这种特殊情况有更好的方法) :

unsigned long long *x;
/* fill data to x*/

for (int i = 0; i < 1000*1000*1000; i++)
{

    A[i]=foo((unsigned char*)x+i);

};

Answer 1

(e.g. how many CPU cycles it takes to convert a pointer/address)

在大多数机器代码语言中，只有一种“类型”的指针，因此在它们之间进行转换不需要任何成本。请记住，C++ 类型实际上只存在于编译时。

真正的问题是这种代码会破坏严格的别名规则。您可以在其他地方阅读更多相关信息，但本质上，编译器要么通过未定义的行为生成不正确的代码，要么被迫做出保守的假设，从而生成更慢的代码。 (注意 char* 和 friends 在某种程度上不受未定义行为部分的影响)

Optimizers often have to make conservative assumptions about variables in the presence of pointers. For example, a constant propagation process that knows the value of variable x is 5 would not be able to keep using this information after an assignment to another variable (for example, *y = 10) because it could be that *y is an alias of x. This could be the case after an assignment like y = &x.

As an effect of the assignment to *y, the value of x would be changed as well, so propagating the information that x is 5 to the statements following *y = 10 would be potentially wrong (if *y is indeed an alias of x). However, if we have information about pointers, the constant propagation process could make a query like: can x be an alias of *y? Then, if the answer is no, x = 5 can be propagated safely. Another optimization impacted by aliasing is code reordering. If the compiler decides that x is not aliased by *y, then code that uses or changes the value of x can be moved before the assignment *y = 10, if this would improve scheduling or enable more loop optimizations to be carried out.

To enable such optimizations in a predictable manner, the ISO standard for the C programming language (including its newer C99 edition, see section 6.5, paragraph 7) specifies that it is illegal (with some exceptions) for pointers of different types to reference the same memory location. This rule, known as "strict aliasing", sometime allows for impressive increases in performance,[1] but has been known to break some otherwise valid code. Several software projects intentionally violate this portion of the C99 standard. For example, Python 2.x did so to implement reference counting,[2] and required changes to the basic object structs in Python 3 to enable this optimisation. The Linux kernel does this because strict aliasing causes problems with optimization of inlined code.[3] In such cases, when compiled with gcc, the option -fno-strict-aliasing is invoked to prevent unwanted optimizations that could yield unexpected code. [edit]

http://en.wikipedia.org/wiki/Aliasing_(computing)#Conflicts_with_optimization

What is the strict aliasing rule?