Editing Aliasing (computing) (section)

== Conflicts with optimization ==
[[Optimizing compiler|Optimizers]] often have to make conservative assumptions about variables when aliasing is possible. For example, knowing the value of a variable (such as <code>x</code> is 5) normally allows certain optimizations (such as [[constant folding#Constant propagation|constant propagation]]). However, the compiler cannot use this information after an assignment to another variable (for example, in C, <code>*y = 10</code>) because it could be that <code>*y</code> is an alias of <code>x</code>. This could be the case after an assignment like <code>y = &x</code>. As an effect of this assignment to <code>*y</code>, the value of <code>x</code> would be changed as well, so propagating the information that <code>x</code> is 5 to the statements following <code>*y = 10</code> would be potentially wrong (if <code>*y</code> is indeed an alias of <code>x</code>). However, if there is information about pointers, the constant propagation process could make a query like: can <code>x</code> be an alias of <code>*y</code>? Then, if the answer is no, <code>x = 5</code> can be propagated safely.

Another optimization impacted by aliasing is code reordering. If the compiler decides that <code>x</code> is not aliased by <code>*y</code>, then code that uses or changes the value of <code>x</code> can be moved before the assignment <code>*y = 10</code>, if this would improve [[instruction scheduling|scheduling]] or enable more [[loop optimization]]s to be carried out.

To enable such optimizations in a predictable manner, [[C (programming language)#ANSI C and ISO C|the ISO standard]] for the [[C (programming language)|C programming language]] (including its newer [[C (programming language)#C99|C99]] edition, see section 6.5, paragraph 7) specifies that it is illegal (with some exceptions) to access the same memory location using pointers of different types. A compiler may therefore assume that such pointers do not alias. This rule, known as the '''strict aliasing rule''', sometimes allows for impressive increases in performance,<ref>{{cite web | url=http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html |author=Mike Acton |date=2006-06-01 |title=Understanding Strict Aliasing}}</ref> but has been known to break some otherwise valid code. Several software projects intentionally violate this portion of the C99 standard. For example, [[CPython|Python 2.x]] did so to implement [[reference counting]],<ref>{{cite web | url=http://mail.python.org/pipermail/python-dev/2003-July/036898.html |author=Neil Schemenauer |date=2003-07-17 |title=ANSI strict aliasing and Python}}</ref> and required changes to the basic object structs in Python 3 to enable this optimization. The [[Linux kernel]] does this because strict aliasing causes problems with optimization of inlined code.<ref>{{cite web | url=https://lkml.org/lkml/2003/2/26/158 |author=Linus Torvalds |date=2003-02-26 |title=Re: Invalid compilation without -fno-strict-aliasing}}</ref> In such cases, when compiled with [[GNU Compiler Collection|gcc]], the option <code>-fno-strict-aliasing</code> is invoked to prevent unwanted optimizations that could yield unexpected code.