On 10/11/07, Steven Watanabe <steven@providere-consulting.com> wrote:
AMDG
Simonson, Lucanus J <lucanus.j.simonson <at> intel.com> writes:
If the function call is inline the compiler knows whether the pointer is the same or not and if it does not know it does not reorder the instructions because it *might* be the same.
What I'm saying is that compiler "knows" that the two pointers are not the same because if they are the same you have undefined behavior anyway so it's not non-conformant if it does something strange.
Yes, this is very important! There is lots of code around that started breaking when compilers started doing type based alias analysis (practically all code that relied on undefined reinterpret casts which were "practically safe"). Just because it works with current compilers, It doesn't means it won't break with future ones when they'll get smarter and smarter. In the example shown by Steven, if b where declared static or in an anonymous namespace I think that a compiler might reorder even if 'modify' is in another compilation unit if it can prove that the address of b is never taken. And with current link time optimizations technologies, not even an out of line function is a useful optimization barrier.
In the back-end the compiler doesn't have any idea what object type the pointer was anymore and certainly doesn't use that information to outsmart itself. The compiler is pessimistic and conservative in nature in the optimizations it makes. If compiler providers chose to do what you suggest they might then they would catch no end of grief until they rolled back the change.
That might have been true some years ago. Current compilers are pretty aggressive when optimizing and will rely on every dark corner of the specs as possible. And will do more so in the future. gpd