These issues are why various compiler hints exist.<p>In the dead code example, the gcc function attribute 'const' can be applied to the declaration of bar(), telling the compiler that it is a pure function whose result depends on nothing but its arguments.<p>In the pointer example, the C99 standard 'restrict' qualifier can be applied to a, b and c to tell the compiler that the values pointed to by these variables do not overlap.<p>'restrict' will also help the global variable example - the reason that N is loaded each time around the loop is because as far as the compiler knows, one of the a[i]s could alias with N.
I'm glad to see pointer aliasing mentioned here. Back in the day, I was writing fluid mechanics simulations in FORTRAN. Writing in FORTRAN is awful, of course, so I did some research into why FORTRAN is considered to be faster than C++ for these simulations. Of course, a lot of it is history, and the fact that the people writing the simulations are engineers first and programmers a distant second, but another thing that seemed to come up was that due to pointer aliasing (which was absent in fortran, or at least made more explicit), FORTRAN compilers were able to implement some important optimizations that C++ compilers couldn't. I wanted to experiment a little bit with the C99 restrict keyword, to see if it would produce similar results to FORTRAN, but I never really got around to it.
Although it's a poorly titled article, it was interesting to read. Surely the objective is to trick the compiler into generating the best code. I was surprised that the vectorisation it mentions was not performed automatically.<p>One other way would be to target different hardware than it's designed to work with via flags, or by using AMD with the intel compiler mentioned in the article. There was a very short discussion about this on reddit yesterday
<a href="http://www.reddit.com/r/programming/comments/lj1ze/ask_rprogramming_do_intel_compilers_still_screw/" rel="nofollow">http://www.reddit.com/r/programming/comments/lj1ze/ask_rprog...</a>
<i>When I declared N as a global variable, the compiler left it in memory and added a load instruction to the loop. When I put N as a local variable, the compiler loaded it into a register. While I do blame the compiler for this particular behavior (because I did not declare N as volatile), we have to work with what we have.</i><p>This is because global variables can be modified at runtime unless they're const. The compiler cannot guarantee it hasn't been declared extern and modified by some other file without sufficiently powerful link-time optimization.